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Preface 



The fourth conference in the series of international meetings on Integrated For- 
mal Methods, IFM, was held in Canterbury, UK, 4-7 April 2004. The conference 
was organized by the Computing Laboratory at the University of Kent, whose 
main campus is just outside the ancient town of Canterbury, part of the county 
of Kent. 

Kent is situated in the southeast of England, and the university sits on a 
hill overlooking the city of Canterbury and its world-renowned cathedral. The 
University of Kent was granted its Royal Charter in 1965. Today there are almost 
10,000 full-time and part-time students, with over 110 nationalities represented. 

The IFM meetings have proven to be particularly successful. The first mee- 
ting was held in York in 1999, and subsequently we held events in Germany in 
2000, and then Finland in 2002. The conferences are held every 18 months or so, 
and attract a wide range of participants from Europe, the Americas, Asia and 
Australia. The conference is now firmly part of the formal methods conference 
calendar. The conference has also evolved in terms of themes and subjects re- 
presented, and this year, in line with the subject as a whole, we saw more work 
on verification as some of the challenges in this subject are being met. 

The work reported at IFM conferences can be seen as part of the attempt to 
manage complexity by combining paradigms of specification and design, so that 
the most appropriate design tools are used at different points in the life-cycle. 
In part this is about combining specification formalisms, and this happens, for 
example, when one combines state-based and event-based languages to produce 
integrated notations capable of covering a wider range of the design spectrum 
than would otherwise be feasible. However, the work of IFM goes beyond that, 
as we can see in this proceedings. 

Indeed, increasingly specification is only the start of a process that includes 
verification as an explicit aim, and this work was heavily represented in this 
year’s conference. This was also reflected in the talks by invited speakers who 
represented both academic and industry perspectives on the subject. 

Tom Ball talked about his team’s work on SLAM and the static driver verifier, 
and described the use of formal methods in Microsoft. Ursula Martin, of Queen 
Mary, University of London, talked about her work on design verification for 
control engineering, and Tom Melham of Oxford gave a talk entitled “Integrating 
Model Checking and Theorem Proving in a Reflective Functional Language.” 
Tom Ball’s talk was sponsored by FME (Formal Methods Europe), to whom 
we are particularly grateful. FME also held their Annual General Meeting on 
the Sunday prior to the main conference. We are also grateful to Jim Woodcock 
for agreeing to give a tutorial on the Unifying Theories of Programming, jointly 
with Ana Cavalcanti. FORTEST, a UK national network on Formal Methods 
and Testing, also joined us for the final day when members attended talks on 
testing and then held an informal workshop after the main conference. 
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The contributed talks were grouped into a number of sessions, this year 
covering: 

— Automating program analysis 

— State-/event-based verification 

— Formalizing graphical notations 

— Refinement 

— Object orientation 

— Hybrid and timed automata 

— Integration frameworks 

— Verifying interactive systems 

— Testing and assertions 

In total there were 65 submissions, of which we accepted 24 after the usual 
refereeing process. We are grateful to all those involved in the reviewing process 
and subsequent programme committee discussion. An important note of thanks 
must also be given to all those who helped locally. 

We hope that these proceedings will serve as a useful source of reference 
for not only the attendees, but also the wider community. We look forward to 
further IFM meetings where we can continue the discussion on the best ways to 
engineer both hardware and software systems with the ultimate aim of increased 
reliability and robustness. 
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SLAM and Static Driver Verifier: Technology 
Transfer of Formal Methods inside Microsoft 



Thomas Ball, Byron Cook, Vladimir Levin, and Sriram K. Rajamani 
Microsoft Corporation 



Abstract. The SLAM project originated in Microsoft Research in early 
2000. Its goal was to automatically check that a C program correctly uses 
the interface to an external library. The project used and extended ideas 
from symbolic model checking, program analysis and theorem proving in 
novel ways to address this problem. The SLAM analysis engine forms the 
core of a new tool called Static Driver Verifier (SDV) that systematically 
analyzes the source code of Windows device drivers against a set of rules 
that define what it means for a device driver to properly interact with 
the Windows operating system kernel. 



We believe that the history of the SLAM project and SDV is an infor- 
mative tale of the technology transfer of formal methods and software 
tools. We discuss the context in which the SLAM project took place, the 
first two years of research on the SLAM project, the creation of the SDV 
tool and its transfer to the Windows development organization. In doing 
so, we call out many of the basic ingredients we believe to be essential 
to technology transfer: the choice of a critical problem domain; standing 
on the shoulders of those who have come before; the establishment of 
relationships with “champions” in product groups; leveraging diversity 
in research and development experience and careful planning and honest 
assessment of progress towards goals. 



1 Introduction 

In the early days of computer science, the ultimate goal of formal methods and 
program verification was to provide technology that could rigorously prove pro- 
grams fully correct. While this goal remains largely unrealized, many researchers 
now focus on the less ambitious but still important goal of stating partial spec- 
ifications of program behavior and providing methodologies and tools to check 
their correctness. The growing interest in this topic is due to the technological 
successes and convergence of four distinct research areas-type checking, model 
checking, program analysis, and automated deduction-on the problems of soft- 
ware quality. Ideas about specification of properties, abstraction of programs, 
and algorithmic analyses from these four areas are coming together in new ways 
to address the common problem of software quality. 



E. Boiten, J. Derrick, G. Smith (Eds.): IFM 2004, LNCS 2999, pp. 1-20, 2004. 
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The SLAM 1 project is just one of many exploring this idea. In early 2000 we 
set out to build a software tool that could automatically check that a C program 
correctly uses the interface to an external library. The outcome of this project 
is the SLAM analysis engine, which forms the core of a soon-to-be-released tool 
called Static Driver Verifier (SDV). SDV systematically analyzes the source code 
of Windows device drivers against a set of rules that define what it means for 
a device driver to properly interact with the Windows kernel, the heart of the 
Windows operating system (referred to as “Windows” from now on). In effect, 
SDV tests all possible execution paths through the C code. 

To date, we have used SDV internally to find defects in Microsoft-developed 
device drivers, as well as in the sample device drivers that Microsoft provides 
in the Windows Driver Development Kit (DDK). However, the most important 
aspect of Window’s stability is the quality of the device drivers written outside 
of Microsoft, called third-party drivers. For this reason we are now preparing 
SDV for release as part of the DDK. 

We have written many technical research papers about SLAM but we have 
never before written a history of the non-technical aspects of the project. Our 
goal is to discuss the process of technology transfer from research to development 
groups and to highlight the reasons we believe that we have been successful to 
date, some of which are: 

— Choice of Problem: We chose a critical, but not insurmountable, problem 
domain to work on (device drivers). We had access to the Windows source 
code and the source code of the device drivers. We also had extensive access 
to the foremost experts on device drivers and Windows. 

— Standing on Shoulders : SLAM builds on decades of research in formal meth- 
ods and programming languages. We are fortunate to have had many people 
contribute to SLAM and SDV, both in Microsoft Research, the Windows 
division, as well as from outside Microsoft. 

— Research Environment: Microsoft’s industrial research environment and gen- 
eral “hands-on/can-do” culture allowed us great freedom in which to attempt 
a risky solution to a big problem, and provided support when we needed it 
the most. 

— Software Engineering : We developed SLAM in an “open” architectural style 
using very simple conceptual interfaces for each of its core components. This 
allowed us to experiment quickly with various tools and settle on a set of 
algorithms that we felt best solved the problem. This architecture also allows 
us to reconfigure the various components easily in response to new problems. 

— The Right Tools for the Job : We developed SLAM using INRIA’s O’Caml 
functional programming language. The expressiveness of this language and 
robustness of its implementation provided a great productivity boost. 

— Good Luck: We experienced good luck at many points over the past four 
years and fortunately were able to take advantage of it. 

1 SLAM originally was an acronym but we found it too cumbersome to explain. We 
now prefer to think of “slamming” the bugs in a program. 
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While some of these factors may be unique to our situation, many are the ba- 
sic ingredients of successful research, development, and technology transfer. We 
believe that the history of our project makes an interesting case study in the 
technology transfer of formal methods and software tools in industry. 

We tell the story in four parts. Section 2 discusses the context in which the 
SLAM and SDV projects took place. In particular, this section provides back- 
ground on Windows device drivers and Microsoft Research. Section 3 discusses 
the first two years of the SLAM project, when the bulk of the research took 
place. Section 4 discusses the development of the Static Driver Verifier tool and 
its transfer to the Windows development organization. Section 5 concludes with 
an analysis of the lessons we learned from our four year experience and a look 
at the future. 



2 Prologue 

We will now provide some pre-SLAM history so that the reader will better 
understand the context in which our project originated. 



2.1 Windows Device Drivers 

Windows hides from its users many details of the myriad hardware components 
that make up a personal computer (PC). PCs are assembled by companies who 
have purchased many of the PC’s basic components from other companies. The 
power of Windows is that application programmers are still able to write pro- 
grams that work using the interface provided by Windows with little to no 
concern for the underlying hardware that their software eventually will execute 
on. 

Examples of devices include keyboards, mice, printers, graphics and audio 
cards, network interface cards, cameras, and a number of storage devices, such 
as CD and DVD drives. Device drivers are the software that link the component 
devices that constitute a PC, as well as its peripheral devices, to Windows. 
The number of devices and device drivers for Windows is enormous, and grows 
every day. While only about 500 device drivers ship on a Windows CD, data 
collected through Microsoft’s Online Crash Analysis (OCA) tool shows orders 
of magnitude more device drivers deployed in the field. 

Most device drivers run within the Windows kernel, where they can run most 
efficiently. Because they execute in the kernel, poorly written device drivers can 
cause the Windows kernel (and thus the entire operating system) to crash or 
hang. Of course, such device driver failures are perceived by the end-user as a 
failure of Windows, not the device driver. Driver quality is a key factor in the 
Windows user experience and has been a major source of concern within the 
company for many years. 

The most fundamental interface that device drivers use to communicate with 
the Windows kernel is called the Windows Driver Model (WDM) . As of today, 
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this interface includes over 800 functions providing access to various kernel facili- 
ties: memory allocation, asynchronous I/O, threads, events, locking and synchro- 
nization primitives, queues, deferred procedure calls, interrupt service routines, 
etc. Various classes of drivers (network drivers, for example) have their own 
driver models, which provide device-specific interfaces on top of the WDM to 
hide its complexity. 

Microsoft provides the Driver Development Kit (DDK) to aid third-parties in 
writing device drivers. The DDK contains the Microsoft compiler for the C and 
C++ languages, supporting tools, documentation of the WDM and other driver 
models, and the full source code of many drivers that ship on the Windows 
CD. The DDK also contains a number of software tools specifically oriented 
towards testing and analyzing device drivers. One is a tool called Driver Verifier, 
which finds driver bugs while the drivers execute in real-time in Windows. In 
addition to the DDK, Microsoft has a driver certification program whose goal is 
to ensure that drivers digitally signed by Microsoft meet a certain quality bar. 
Finally, Microsoft uses the OCA feature of Windows to determine which device 
drivers are responsible for crashes in the field. This data is made available to 
Microsoft’s partners to ensure that error-prone drivers are fixed as quickly as 
possible. Despite all these measures, drivers are a continuing source of errors. 
Developing drivers using a complex legacy interface such as WDM is just plain 
hard. (This is not just true of Windows-Engler found the error rate in Linux 
device drivers was much higher than for the rest of the Linux kernel [CYC + 01]). 

Device drivers are a great problem domain for automated analysis because 
they are relatively small in size (usually less that 100,000 lines of C code), and 
because most of the WDM usage rules are control-dominated and have little 
dependence on data. On the other hand, drivers use all the features of the C 
language and run in a very complex environment (the Windows kernel), which 
makes for a challenging analysis problem. 

One of the most difficult aspects of doing work in formal methods is the issue 
of where specifications come from, and the cost of writing and maintaining them. 
A welcome aspect of the WDM interface, from this perspective, is that the cost 
of writing the specifications can be amortized by checking the same specifications 
over many WDM drivers. Interfaces that are widely used (such as the WDM) 
provide good candidates for applying formal methods, since specifications can 
be done at the level of the interface and all clients that use the interface can be 
analyzed automatically for consistent usage of the interface with respect to the 
specifications. 

2.2 Microsoft Research 

Over the past decade, Microsoft Research (MSR) has grown to become one of 
the major industrial research organizations in basic computer science, with over 
600 researchers in five labs worldwide. 

It is worthwhile to note the major differences between industrial research, 
as found in Microsoft, and research at academic institutions. First, there is no 
tenure in MSR, as in academia. Performance reviews take place every year, as 
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done in corporate America. Second, performance is measured not only by contri- 
butions to basic science (one measure of which is peer-reviewed publications) but 
also by contributions to Microsoft. Balancing long-term basic research with more 
directed work for the company is one of the most challenging but also the most 
rewarding aspects of industrial research. Third, working with other researchers 
within MSR (as well as outside) is encouraged and rewarded. Fourth, there are 
no graduate students. Instead, during three brief summer months each year, we 
are fortunate to attract high quality graduate students for internships. One final 
thing is worth noting: MSR generally puts high value on seeing ideas take form 
in software, as this is the major mechanism for demonstrating value and enabling 
technology transfer within Microsoft. To say this in a different way: developers 
are not the only Microsoft employees who program computers; researchers also 
spend a good deal of time creating software to test their ideas. As we discovered 
in SLAM, new research insights often come from trying to take an idea from 
theory to practice through programming. 

The Programmer Productivity Research Center (PPRC) is a research and 
development center in MSR whose charter is “to radically improve the effective- 
ness of software development and the quality of Microsoft software” . Founded 
in March of 1999, PPRC’s initial focus was on performance tools but quickly 
grew to encompass reliability tools with the acquisition of Intrinsa and its PRE- 
fix defect detection tool [BPSOO]. The PREfix technology has been deployed in 
many of Microsoft’s product groups. More than twelve percent of the bugs fixed 
before Windows 2003 server shipped were found with the PREfix and PREfast 
tools, which are run regularly over the entire Windows source base. PPRC has 
developed an effective infrastructure and pipeline for developing new software 
tools and deploying them throughout the company. 

3 SLAM (2000-2001) 

So, the stage is set to tell the story of SLAM. Device drivers were (and still are) a 
key problem of concern to the company. PPRC, which supports basic research in 
programming languages, formal methods and software engineering, was seeking 
to improve development practices in Microsoft through software tools. In this 
section, we describe the first two years of the SLAM project. 

3.1 Software Productivity Tools 

SLAM was one of the initial projects of the Software Productivity Tools (SPT) 
group within PPRC, founded by Jim Larus. The members of this group were Tom 
Ball, Manuvir Das, Rob DeLine, Manuel Fahndrich, Jim Larus, Jakob Rehof 
and Sriram Rajamani. The SPT group spent its first months brainstorming 
new project ideas and discussing software engineering problems. The problem of 
device drivers was one of the topics that we often discussed. 

Three projects came out of these discussions: SLAM, Vault [DF01], and 
ESP [DLS02]. Each of these projects had a similar goal: to rigorously check that 
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a program obeys “interface usage rules”. The basic differences in the projects 
were in the way the rules were specified and in the analysis technology used. 
Vault was a new programming language with an extended type system in which 
the rules were specified using pre-/post-conditions attached to types. ESP and 
SLAM shared a similar specification language but took different approaches to 
addressing the efficiency /precision tradeoffs inherent in program analysis. (For 
a more detailed comparison of these three projects, see [LBD + 04].) 

Having several projects working in friendly competition on a common prob- 
lem made each project stronger. We benefited greatly from many technical dis- 
cussions with SPT members. All three projects are still active today: Manuvir 
now leads a group based on the ESP project to extend the scope and scale of 
static analysis tools; Rob and Manuel retargeted the Vault technology to MSIL 
(Microsoft’s Intermediate Language, a byte-code like language for Microsoft’s 
new virtual machine, the Common Language Runtime) and extended its ca- 
pabilities. This analyzer is called Fugue [DF04] and is a plug-in to the Visual 
Studio programming environment and will be available soon as part of the freely- 
available FxCop tool. 

3.2 A Productive Peer Partnership 

SLAM was conceived as the result of conversations between Tom and Sriram 
on how symbolic execution, model checking and program analysis could be com- 
bined to solve the interface usage problem for C programs (and drivers in partic- 
ular). Tom’s background was in programming languages and program analysis, 
while Sriram’s background was in hardware verification and model checking. 
Both had previous experience in industry. Tom worked six years as a researcher 
in Bell Labs (at AT&T and then Lucent Technologies) after his Ph.D. and Sri- 
ram worked over five years at Syntek and Xilinx before his Ph.D. Two months of 
initial discussions and brainstorming at the end of 1999 led to a technical report 
published in January of 2000 [BROOb] that contained the basic ideas, theory and 
algorithms that provided the initial foundation for the SLAM project. 

Our basic idea was that checking a simple rule against a complex C program 
(such as a device driver) should be possible by simplifying the program to make 
analysis tractable. That is, we should be able to find an abstraction of the original 
C program that would have all of the behaviors of the original program (plus 
additional ones that did not matter when checking the rule of interest). 

The basic question we then had to answer was “What form should an ab- 
straction of a C program take?”. We proposed the idea of a Boolean program, 
which would have the same control flow structure as the original C program but 
only permit the declaration of Boolean variables. These Boolean variables would 
track important predicates over the original program’s state (such as x < 5). 

We found Boolean programs interesting for a number of reasons. First, be- 
cause the amount of storage a Boolean program can access at any point is finite, 
questions of reachability and termination (which are undecidable in general) 
are decidable for Boolean programs. Second, as Boolean programs contain the 
control-flow constructs of C, they form a natural target for investigating model 
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checking of software. Boolean programs can be thought of as an abstract repre- 
sentation of C programs in which the original variables are replaced by Boolean 
variables that represent relational observations (predicates) between the original 
variables. As a result, Boolean programs are useful for reasoning about properties 
of the original program that are expressible through such observations. 

Once we fixed Boolean programs as our form of abstraction, this led us 
naturally to an automated process for abstraction, checking and refinement of 
Boolean programs in the spirit of Kurshan [Kur94] : 

— Abstract. Given a C program P and set of predicates E, the goal of this 
step is to efficiently construct a precise Boolean program abstraction of P 
with respect to E. Our contribution was to extend the predicate abstraction 
algorithm of Graf and Saidi [GS97] to work for programs written in common 
programming languages (such as C). 

— Check. Given a Boolean program with an error state, the goal of this step 
is to check whether or not the error state is reachable. Our contribution was 
to solve this problem by using a data structure called Binary Decision Dia- 
grams [Bry86,BCM + 92] from the model checking community in the context 
of traditional interprocedural dataflow analysis [SP81,RHS95]. 

— Refine. If the Boolean program contains an error path and this path is a fea- 
sible execution path in the original C, then the process has found a potential 
error. If this path is not feasible in the C program then we wish to refine the 
Boolean program so as to eliminate this false error path. Our contribution 
was to show how to use symbolic execution and a theorem prover [DNS03] 
to find a set of predicates that, when injected into the Boolean program on 
the next iteration of the SLAM process, would eliminate the false error path. 

In the initial technical report, we formalized the SLAM process and proved 
its soundness for a language with integer variables, procedures and procedure 
calls but without pointers. Through this report we had laid out a plan and a 
basic architecture that was to remain stable and provide a reference point as 
we progressed. Additionally, having this report early in the life of the project 
helped us greatly in recruiting interns. The three interns who started on the 
SLAM project in the summer of 2000 had already digested and picked apart the 
technical report before they arrived. 

After we had written the technical report we started implementing the Check 
step in the Bebop model checker [BR00a,BR01a]. Although only one of the three 
steps in SLAM was implemented, it greatly helped us to explore the SLAM 
process as we could simulate the other two steps by hand (for small examples). 
Furthermore, without the Check step, we could not test the Abstract step, 
which we planned to implement in the summer. 

During the implementation of Bebop, we often worked side-by-side as we 
developed code. We worked to share our knowledge about our respective fields, 
program languages/analysis (Tom) and model checking (Sriram). Working in 
this fashion, we had an initial implementation of Bebop working in about two 
months. 
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With only Bebop working, we manually extracted Boolean program models 
from several drivers and experimented with the entire approach. Then, over the 
summer of 2000, we built the first version of the Abstract step with the help 
of our interns Rupak Majumdar and Todd Millstein. After this was done, we 
experimented with more examples where we manually supplied predicates, but 
automatically ran the Abstract and Check steps. Finally, in the fall of 2000, 
we built the first version of the Refine step. Since this tool discovers predicates 
we named it Newton [BR02a]. We also developed a language called Slic to 
express interface usage rules in a C-like syntax, and integrated it with the rest 
of the tools [BROlb]. 

3.3 Standing on Shoulders 

As we have mentioned before, the ideas that came out of the SLAM project built 
on and/or extended previous results in the areas of program analysis, model 
checking and theorem proving. A critical part to SLAM’s success was not only 
to build on a solid research foundation but also to build on existing technology 
and tools, and to enlist other people to help us build and refine SLAM. 

The parts of SLAM that analyze C code were built on top of existing in- 
frastructure developed in MSR that exports an abstract syntax tree interface 
from the Microsoft C/C++ compiler and that performs alias analysis of C 
code [DasOO]. The Bebop model checker uses a BDD library called CUDD de- 
veloped at The University of Colorado [Som98]. (This library also has been in- 
corporated in various checking tools used within Intel and other companies that 
develop and apply verification technology.) We also relied heavily on the Simplify 
theorem prover from the DEC/Compaq/HP Systems Research Center [DNS03]. 
Finally, the SLAM code base (except for the Bebop model checker) was writ- 
ten in the functional programming language Objective Caml (O’Caml) from 
INRIA [CMP]. Bebop was written in C++. 

In our first summer we were fortunate to have three interns work with us 
on the SLAM project: Sagar Clraki from Carnegie Mellon University (CMU), 
Rupak Majumdar from the University of California (UC) at Berkeley and Todd 
Millstein from the University of Washington. Rupak and Todd worked on the 
first version of the predicate abstraction tool for C programs [BMMR01], while 
Sagar worked with us on how to reason about concurrent systems [BCR01]. After 
returning to Berkeley, Rupak and colleagues there started the BLAST project, 
which took a “lazy” approach to implementing the process we had defined in 
SLAM [HJMS02]. Todd continued to work with us after the summer to finish 
the details of performing predicate abstraction in the presence of procedures and 
pointers [BMR01]. Back at CMU, Sagar started the MAGIC project [CCG + 03], 
which extended the ideas in SLAM to the domain of concurrent systems. 

During these first two years, we also had the pleasure of hosting other visi- 
tors from academia. Andreas Podelski, from the Max Plank Institute, spent his 
sabbatical at MSR and helped us understand the SLAM process in terms of 
abstract interpretation [CC77]. Andreas’ work greatly aided us in understand- 
ing the theoretical capabilities and limitations of the SLAM process [BPR01, 
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BPR02]. Stefan Schwoon, a Ph.D. candidate from the Technical University of 
Miinchen, visited us in the fall of 2001. Stefan had been working on a model 
checking tool [ES01] — called Moped — that was similar to Bebop. We had sent 
him information about Boolean programs, which allowed him to target Moped 
to our format. In a few weeks of work with us, he had a version of SLAM that 
worked with Moped instead of Bebop. As a result, we could directly compare 
the performance of the two model checkers. This led to a fruitful exchange of 
ideas about how to improve both tools. 

Later on, Rustan Leino joined the SPT group and wrote a new Boolean pro- 
gram checker (called “Dizzy”) that was based on translating Boolean programs 
to SAT [Lei03] . This gave us two independent ways to analyze Boolean programs 
and uncovered even more bugs in Bebop. 

Finally, as we mentioned before, the PREfix and PREfast tools blazed the 
trail for static analysis at Microsoft. These two tools have substantially increased 
the awareness within the company of the benefits and limitations of program 
analysis. The success of these tools has made it much easier for us to make a 
case for the next generation of software tools, such as SDV. 



3.4 Champions 

A key part of technology transfer between research and development organiza- 
tions is to have “champions” on each side of the fence. Our initial champions in 
the Windows organization were Adrian Oney, Peter Wielancl and Bob Rinne. 

Adrian is the developer of the Driver Verifier testing tool built into the Win- 
dows operating system (Windows 2000 and on). Adrian spent many hours with 
us explaining the intricacies of device drivers. He also saw the potential for Static 
Driver Verifier to complement the abilities of Driver Verifier, rather than viewing 
it as a competing tool, and communicated this potential to his colleagues and 
management. Peter Wieland is an expert in storage drivers and also advised us 
on the complexities of the driver model. If we found what we thought might be a 
bug using SLAM, we would send email to Adrian and Peter. They would either 
confirm the bug or explain why this was a false error. The latter cases helped 
us to refine the accuracy of our rules. Additionally, Neill Clift from the Win- 
dows Kernel team had written a document called “Common Driver Reliability 
Problems” from which we got many ideas for rules to check. 

Having champions like these at the technical level is necessary but not suffi- 
cient. One also needs champions at the management level with budgetary power 
(that is, the ability to hire people) and the “big picture” view. Bob Rinne was 
our champion at the management level. Bob is a manager of the teams responsi- 
ble for developing many of device drivers and driver tools that Microsoft ships. 
As we will see later, Bob’s support was especially important for SLAM and SDV 
to be transferred to Windows. 
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3.5 The First Bug . . . and Counting 

In initial conversations, we asked Bob Rinne to provide us with a real bug in a 
real driver that we could try to discover with the SLAM engine. This would be 
the first test of our ideas and technology. He presented us with a bug in the floppy 
disk driver from the DDK that dealt with the processing of IRPs (I/O Request 
Packets). In Windows, requests to drivers are sent via IRPs. There are several 
rules that a driver must follow with regards to the management of IRPs. For 
instance, a driver must mark an IRP as pending (by calling IoMarklrpPending) 
if it returns STATUS_PENDING as the result of calling the driver with that IRP. 
The floppy disk driver had one path through the code where the correlation 
between returning STATUS_PENDING and calling IoMarklrpPending was missed. 
On March 9, 2001, just one year after we started implementing SLAM, the tool 
found this bug. 

In the summer of 2001, we were again fortunate to have excellent interns 
working on the SLAM project: Satyaki Das from Stanford, Sagar Clraki (again), 
Robby from Kansas State University and Westley Weimer from UC Berkeley. 
Satyaki and Westley worked on increasing the performance of the SLAM pro- 
cess [ABD + 02,BCDR04] and the number of device drivers to which we could 
successfully apply SLAM. Robby worked with Sagar on extending SLAM to rea- 
son more accurately about programs which manipulate heap data structures. 
Towards the end of the summer Westley and Satyaki found two previously un- 
known bugs in DDK sample drivers using SLAM. 

Manuel Fahndrich developed a diagram of the various legal states and transi- 
tions an IRP can go through by piecing together various bits of documentation, 
and by reading parts of the kernel source code. Using this state diagram, we 
encoded a set of rules for checking IRP state management. With these rules we 
found five more previously unknown bugs in IRP management in various drivers. 

3.6 Summary 

In the first two years of the SLAM project we had defined a new direction 
for software analysis based on combining and extending results from the fields 
of model checking, program analysis and theorem proving, published a good 
number of papers (see references for a full list), created a prototype tool that 
found some non-trivial bugs in device drivers, and had attracted attention from 
the academic research community. The first two years culminated in an invited 
talk which we were asked to present at the Symposium on the Principles of 
Programming Languages in January of 2002 [BR02b]. 

However, as we will see, the hardest part of our job was still ahead of us. As 
Thomas Alva Edison noted, success is due in small part to “inspiration” and in 
large part to “perspiration”. We had not yet begun to sweat. 

4 Static Driver Verifier (2002-2003) 

From an academic research perspective, SLAM was a successful project. But, 
in practice, SLAM could only be applied productively by a few experts. There 




SLAM and Static Driver Verifier 



11 



was a tremendous amount of work left to do so that SLAM could be applied 
automatically to large numbers of drivers. In addition to improving the basic 
SLAM engine, we needed to surround this engine with the framework that would 
make it easy to run on device drivers. The product that solved all of these 
problems was to be called “Static Driver Verifier” (SDV). Our vision was to 
make SDV a fully automatic tool. It had to contain, in addition to the SLAM 
engine, the following components: 

— A large number of rules for the Windows Driver Model (and in future re- 
leases, other driver models as well) -we had written only a handful of rules; 

— A model of the Windows kernel and other drivers, called the environment 
model- we had written a rough model of the environment model in C, but it 
needed to be refined; 

— Scripts to build a driver and configure SDV with driver specific information; 

— A graphical user interface (GUI) to summarize the results of running SDV 
and to show error traces in the source code of the driver. 

SDV was not going to happen without some additional help. 

Having produced promising initial results, we went to Amitablr Srivastava, 
director of the PPRC, and asked for his assistance. He committed to hiring a per- 
son for the short term to help us take SLAM to the next stage of life. Fortunately, 
we had already met just the right person for the task: Jakob Lichtenberg from 
the IT University of Copenhagen. We met Lichtenberg in Italy at the TACAS 
conference in 2001 where we presented work with our summer interns from 2000. 
After attending our talk, Jakob had spent the entire night re-coding one of our 
algorithms in a model checking framework he had developed. We were impressed. 
Lichtenberg joined the SLAM team in early February of 2002 and the next stage 
of the roller-coaster ride began. Jakob was originally hired for six months. In the 
end, he stayed 18 months. 



4.1 TechFest and Bill Gates Review 

The first task Lichtenberg helped us with was preparing a demonstration for an 
internal Microsoft event in late February of 2002 called TechFest. TechFest is 
an annual event put on by MSR to show what it has accomplished in the past 
year and to find new opportunities for technology transfer. TechFest has been an 
incredibly popular event. In 2001, when TechFest started, it had 3,700 attendees. 
In its second year, attendance jumped to 5,200. In 2003, MSR’s TechFest was 
attended by over 7,000 Microsoft employees. 

The centerpiece of TechFest is a demo floor consisting of well over 100 booths. 
In our booth, we showed off the results of running SLAM on drivers from the 
Driver Development Kit of Windows XP. Many driver developers dropped by for 
a demo. In some cases, the author of a driver we had found a bug in was present 
to confirm that we had found a real bug. Additionally, two other important 
people attended the demo: Jim Allchin (head of the Windows platform division) 
and Bill Gates. 
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Two weeks after TechFest (in early March 2002), we made a presentation 
on SLAM as part of a regular review of research by Bill Gates. At this point, 
managers all the way up the management chain in both MSR and Windows (with 
the least-common ancestor being Gates) were aware of SLAM. The rapidity with 
which key people in the company became aware of SLAM and started referring 
to it was quite overwhelming. 



4.2 The Driver Quality Team 

Around this time, a new team in Bob Rinne’s organization formed to focus on 
issues of driver quality. Bob told us that he might be able to hire some people into 
this group, called the Driver Quality Team (DQT), to help make a product out 
of SDV. In the first four months of 2002, we had received a number of resumes 
targeted at the SLAM project. We told Bob of two promising applicants: Byron 
Cook, from the Oregon Graduate Institute (OGI) and Prover Technology, and 
Vladimir Levin, from Bell Labs. Byron was in the process of finishing his Ph.D. 
in Computer Science and had been working on tools for the formal verification of 
hardware and aircraft systems at Prover for several years. Vladimir had a Ph.D. 
in Computer Science and had been working on a formal verification tool at Bell 
Labs for six years. 

By the beginning of July, both Byron and Vladimir were interviewed and 
hired. They would join Microsoft in August and September of 2002, respectively, 
as members of DQT. The importance of the Windows kernel development orga- 
nization hiring two Ph.D.s with formal verification backgrounds and experience 
cannot be overstated. It was another major milestone in the technology transfer 
of SLAM. Technology transfer often requires transfer of expertise in addition to 
technology. Byron and Vladimir were to form the bridge between research and 
development that would enable SLAM to be more successful. 

Nar Ganapathy was appointed as the manager of DQT. Nar is the developer 
and maintainer of the I/O subsystem of the Windows kernel — the piece of the 
kernel that drivers interact with most. This meant that half of the SDV team 
would now be reporting directly to the absolute expert on the behavior of the 
I/O subsystem. 



4.3 SDV 1.0 

Our first internal release of SDV (1.0) was slated for the end of the summer. 
This became the major focus of our efforts during the late spring and summer of 
2002. While in previous years, summer interns had worked on parts of the SLAM 
engine, we felt that the analysis engine was stable enough that we should invest 
energy in problems of usability. Mayur Naik from Purdue University joined as a 
summer intern and worked on how to localize the cause of an error in an error 
trace produced by SLAM [BNR03]. 

On September 03, 2002, we made the release of SDV 1.00 on an internal web- 
site. It had the following components: the SLAM engine, a number of interface 




SLAM and Static Driver Verifier 



13 



usage rules, a model of the kernel used during analysis, a GUI and scripts to 
build the drivers. 

4.4 Fall 2002: Descent into Chaos (SDV 1.1) 

In the autumn of 2002, the SDV project became a joint project between MSR 
and Windows with the arrival of Byron and Vladimir, who had been given offices 
in both MSR and Windows. While we had already published many papers about 
SLAM, there was a large gap between the theory we published and the imple- 
mentation we built. The implementation was still a prototype and was fragile. It 
only had been run on about twenty drivers. We had a small set of rules. Depen- 
dence on a old version of the Microsoft compiler and fundamental performance 
issues prevented us from running on more drivers. 

When Byron and Vladimir began working with the system they quickly ex- 
posed a number of significant problems that required more research effort to 
solve. Byron found that certain kinds of rules made SLAM choke. Byron and 
Vladimir also found several of SLAM’s modules to be incomplete. At the same 
time, a program manager named Johan Marien from Windows was assigned to 
our project part-time. His expectation was that we were done with the research 
phase of the project and ready to be subjected to the standard Windows de- 
velopment process. We were not ready. Additionally, we were far too optimistic 
about the timeframe in which we could address the various research and engi- 
neering issues needed to make the SLAM engine reliable. We were depending 
on a number of external components: O’Caml, the CUDD BDD package, the 
automatic theorem prover Simplify. Legal and administrative teams from the 
Windows organization struggled to figure out the implications of these external 
dependencies. 

We learned several lessons in this transitional period. First, code reviews, 
code refactoring and cleanup activities provide a good way to educate others 
about a new code base while improving its readability and maintainability. We 
undertook an intensive series of meetings over a month and a half to review the 
SLAM code, identify problems and perform cleanup and refactoring to make the 
code easier to understand and modify. Both Byron and Vladimir rewrote several 
modules that were not well understood or buggy. Eventually, ownership of large 
sections of code was transferred from Tom and Sriram to Byron and Vladimir. 
Second, weekly group status meetings were essential to keeping us on track and 
aware of pressing issues. Third, it is important to correctly identify a point in a 
project where enough research has been done to take the prototype to product. 
We had not yet reached that point. 

4.5 Winter 2002/Spring 2003: SDV Reborn (SDV 1.2) 

The biggest problem in the autumn of 2002 was that a most basic element was 
missing from our project, as brought to our attention by Nar Ganapathy: we 
were lacking a clear statement of how progress and success on the SDV project 
would be measured. Nar helped us form a “criteria document” that we could use 
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to decide if SDV was ready for widespread use. The document listed the type 
of drivers that SDV needed to run on, specific drivers on which SDV needed to 
run successfully, some restrictions on driver code (initial releases of SDV were 
not expected to support C++), performance expectations from SDV (how much 
memory it should take, how much time it should take per driver and per rule), 
and the allowable ratio of false errors the tool could produce (one false error per 
four error reports). 

Another problem was that we now had a project with four developers and 
no testers. We had a set of over 200 small regression tests for the SLAM engine 
itself, but we needed more tests, particularly with complete device drivers. We 
desperately needed better regression testing. Tom and Vladimir devoted several 
weeks to develop regression test scripts to address this issue. Meanwhile Byron 
spent several weeks convincing the Windows division to devote some testing 
resources to SDV. As a result of his pressure, Abdullah Ustuner joined the SDV 
team as a tester in February 2003. 

One of the technical problems that we encountered is called NDF, an internal 
error message given by SLAM that stands for “no difference found”. This hap- 
pens when SLAM tries to eliminate a false error path but fails to do so. In this 
case, SLAM halts without having found a true error or a proof of correctness. 
A root cause of many of these NDFs was SLAM’s lack of precision in handling 
pointer aliasing. This led us to invent novel ways to handle pointer aliasing 
during counter-example-driven refinement, which we implemented. SLAM also 
needed to be started with a more precise model of the kernel and possible aliases 
inside kernel data structures, so we rewrote the kernel models and harnesses to 
initialize key data structures. As a result of these solutions, the number of NDFs 
when we shipped SDV 1.2 went down dramatically. Some still remained, but the 
above solutions converted the NDF problem from a show-stopper to a minor 
inconvenience. 

With regression testing in place, a clear criterion from Nar’s document on 
what we need to do to ship SDV 1.2, and reduction of the NDF problem, we 
slowly recovered from the chaos that we experienced in the winter months. SDV 
1.2 was released on March 31st, 2003, and it was the toughest release we all 
endured. It involved two organizations, two different cultures, lots of people, 
and very hard technical problems. We worked days, nights and weekends to 
make this release happen. 

4.6 Taking Stock in the Project: Spring 2003 

Our group had been hearing conflicting messages about what our strategy should 
be. For example, should we make SDV work well on third party drivers and re- 
lease SDV as soon as possible, or should we first apply it widely on our own 
internally developed drivers and find the most bugs possible? Some said we 
should take the first option; others said the latter option was more critical. Our 
group also needed more resources. For example, we needed a full-time program 
manager who could manage the legal process and the many administrative com- 
plications involved in transferring technology between organizations. We desper- 
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ately needed another tester. Additionally, we needed to get a position added in 
the Windows division to take over from Jakob, whose stay at Microsoft was to 
end soon. 

Worst of all, there was a question as to whether SDV had been successful or 
not. From our perspective, the project had been a success based on its reception 
by the formal verification research community and MSR management. Some 
people within the Windows division agreed. Other members of the Windows 
division did not. The vast majority of people in the Windows division were not 
sure and wanted someone else to tell them how they should feel. 

Byron decided that it was time to present our case to the upper management 
of the Windows division and worked with Nar to schedule a project review 
with Windows vice-president Rob Short. We would show our hand and simply 
ask the Windows division for the go-ahead to turn SDV into a product. More 
importantly, a positive review from Rob would help address any lingering doubts 
about SDV’s value within his organization. 

We presented our case to Rob, Bob Rinne and about ten other invited guests 
on April 28th 2003. We presented statistics on the number of bugs found with 
SDV and the group’s goals for the next release: we planned on making the 
next release available at the upcoming Windows Driver Development Conference 
(DDC), where third-party driver writers would apply SDV to their own drivers. 
We made the case for hiring three more people, (a program manager, another 
tester and developer to take over from Jakob) and buying more machines to 
parallelize runs of SDV. In short order, Rob gave the “thumbs-up” to all our 
plans. It was time to start shopping for people and machines. 

4.7 Summer/Fall 2003: The Driver Developer Conference (SDV 
1.3) 

Ideally we would have quickly hired our new team-members, bought our ma- 
chines and then began working on the next release. However, it takes time to 
find the right people, as we found out. At the end of May, John Henry joined 
the SDV group as our second tester. Bolrus Ondrusek would eventually join the 
SDV team as our program manager in September. Con McGarvey later joined 
as a developer in late September. Jakob Lichtenberg left to return to Denmark 
at about the same time. By the time we had our SDV 1.3 development team put 
together, the Driver Developer Conference was only a month away. 

Meanwhile, we had been busy working on SLAM. When it became clear that 
we would not know if and when our new team-members would join, we decided 
to address the following critical issues for the DDC event: 

— More expressiveness in the SLIC rule language. 

— More rules. We added more than 60 new rules that were included in the 
DDC distribution of SDV. 

— Better modeling of the Windows kernel. While not hoping to complete our 
model of the kernel by the DDC, we needed to experiment with new ways to 
generate models. A summer intern from the University of Texas at Austin 
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named Fei Xie spent the summer trying a new approach in which SLAM’s 
analysis could be used to train with the real Windows code and find a model 
that could be saved and then reused [BLX04]. Abdullah wrote a tool that 
converted models created by PREfix for use by SLAM. 

— Better integration with the “driver build” environment used by driver writ- 
ers. This included supporting libraries and the new C compiler features used 
by many drivers. 

— Removal of our dependency on the Simplify theorem prover. SLAM uses 
a first-order logic theorem prover during the Abstract and Refine steps 
described in Section 3.2. Up until this time we had used Simplify. But the 
license did not allow us to release SLAM based on this prover. Again, we 
relied on the help of others. Slruvendu Lalriri, a graduate student from CMU 
with a strong background in theorem proving, joined us for the summer 
to help create a new theorem prover called “Zapato”. We also used a SAT 
solver created by Lintao Zhang of MSR Silicon Valley. By the fall of 2003, 
we had replaced Simplify with Zapato in the SLAM engine, with identical 
performance and regression results. [BCLZ04] 

In the end, the release of SDV 1.3 went smoothly. We released SDV 1.3 on 
November 5tlr, a week before the DDC. The DDC event was a great success. 
Byron gave two presentations on SDV to packed rooms. John ran two labs in 
which attendees could use SDV on their own drivers using powerful AMD64- 
based machines. Almost every attendee found at least one bug in their code. 
The feedback from attendees was overwhelmingly positive. In their surveys, the 
users pleaded with us to make a public release of SDV as soon as possible. 

The interest in SDV from third-party developers caused even more excite- 
ment about SDV within Microsoft. Some of the attendees of the DDC were 
Microsoft employees who had never heard of SDV. After the DDC we spent 
several weeks working with new users within Microsoft. The feedback from the 
DDC attendees also helped us renew our focus on releasing SDV. Many nice fea- 
tures have not yet been implemented. On some drivers the performance could be 
made much better. But, generally speaking, the attendees convinced us (while 
the research in this class of tools is not yet done) that we have done enough 
research in order to make our first public release. 

4.8 Summary 

As of the beginning of 2004, the SDV project has fully transferred from Microsoft 
Research to Windows. There are now six people working full-time on SDV in 
Windows: Abdullah, Bolrus, Byron, Con, John and Vladimir. Sriram and Tom’s 
involvement in the project has been reduced to “consultancy” ; they are no longer 
heavily involved in the planning or development of the SLAM/SDV technology 
but are continuing research that may eventually further impact SDV . 

5 Epilogue: Lessons Learned and the Future 

We have learned a number of lessons from the SLAM/SDV experience: 
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Focus on Problems not Technology. It is easier to convince a product group to 
adopt a new solution to a pressing problem that they already have. It is very 
hard to convince a product group to adopt new technology if the link to the 
problem that it solves is unclear. Concretely, we do not believe that trying to 
transfer the SLAM engine as an analysis vehicle could ever work. However, 
SDV as a solution to the driver reliability problem is an easier concept to 
sell to a product group (We thank Jim Larus for repeatedly emphasizing the 
important difference between problem and solution spaces). 

Exploit Synergies. It was the initial conversations between Tom and Sriram 
that created the spark that became the SLAM project. We think it is a 
great idea for people to cross the boundaries of their traditional research 
communities to collaborate with people from other communities and to seek 
diversity in people and technologies when trying to solve a problem. We 
believe that progress in research can be accelerated by following this recipe. 
Plan Carefully. As mentioned before, research is a mix of a small amount 
inspiration and a large amount of perspiration. To get maximum leverage in 
any research project, one has to plan in order to be successful. In the SLAM 
project, we have spent long hours planning intern projects and communicat- 
ing with interns long before they even showed up at MSR. We think that it is 
crucial not to underestimate the value of such ground work. Usually, we have 
had clarity on what problems interns and visitors would address even before 
they visit. However, our colleagues had substantial room for creativity in the 
approaches used to solve these problems. We think that such a balance is 
crucial. Most of our work with interns and visitors turned into conference 
papers in premier conferences. 

Maintain Continuity and Ownership. Interns and visitors can write code but 
then they leave! Someone has to maintain continuity of the research project 
going. We had to spend several months consolidating code written by interns 
after every summer, taking ownership of it, and providing continuity for the 
project. 

Reflect and Assess. In a research project that spans several years, it is im- 
portant to regularly reassess the progress you are making towards your main 
goal. In the SLAM project we did several things that were interesting tech- 
nically (for example, checking concurrency properties with counting abstrac- 
tions, heap-logics, etc.) but in the end did not contribute substantially to 
our main goal of checking device driver rules. We reassessed and abandoned 
further work on such sub-projects. Deciding what to drop is very important, 
otherwise one would have too many things to do, and it would be hard to 
achieve anything. 

Avoid the Root of All Evil. It is important not to optimize prematurely. We 
believe it is best to let the problem space dictate what you will optimize. 
For example, we used a simple greedy heuristic in Newton to pick relevant 
predicates and we have not needed to change it to date! We also had the ex- 
perience of implementing complicated optimizations that we thought would 
be beneficial but were hard to implement and were eventually abandoned 
because they did not produce substantial improvements. 
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— Balance Theory and Practice. In hindsight, we should have more carefully 
considered the interactions of pointers and procedures in the SLAM process, 
as this became a major source of difficulty for us later on (see Section 4.5). 
Our initial technical report helped us get started and get our interns going, 
but many difficult problems were left unsolved and unimagined because we 
did not think carefully about pointers and procedures. 

— Ask for Help. One should never hesitate to ask for help, particularly if it is 
possible to get help. With SLAM/SDV, in retrospect, we wish we had asked 
for help on testing resources sooner. 

— Put Yourself in Another’s Shoes. Nothing really helped us to prepare for how 
the product teams operate, how they allocate resources, and how they make 
decisions. One person’s bureaucracy is another’s structure. Companies with 
research labs need to help researchers understand how to make use of that 
structure. On the other hand, researchers have to make a good faith effort 
to understand how product teams operate and learn about what it takes to 
turn a prototype into a product. 

At this point, SLAM has a future as an analysis engine for SDV. Current re- 
search that we are doing addresses limitations of SLAM, such as dealing with 
concurrency, more accurately reasoning about data structures, and scaling the 
analysis via compositional techniques. We also want to question the key assump- 
tions we made in SLAM, such as the choice of the Boolean program model. We 
also hope that the SLAM infrastructure will be used to solve other problems. For 
example, Shaz Qadeer is using SLAM to find races in multi-threaded programs. 

Beyond SLAM and SDV, we predict that in the next five years we will see 
partial specifications and associated checking tools widely used within the soft- 
ware industry. These tools and methodologies eventually will be integrated with 
widely used programming languages and environments. Additionally, for critical 
software domains, companies will invest in software modeling and verification 
teams to ensure that software meets a high reliability bar. 



Acknowledgements. We wish to thank everyone mentioned in this paper for 
their efforts on the SLAM and SDV projects, and to the many unnamed re- 
searchers and developers whose work we built on. 
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Abstract. We introduce control engineering as a new domain of ap- 
plication for formal methods. We discuss design verification, drawing 
attention to the role played by diagrammatic evaluation criteria involv- 
ing numeric plots of a design, such as Nichols and Bode plots. We show 
that symbolic computation and computational logic can be used to dis- 
charge these criteria and provide symbolic, automated, and very general 
alternatives to these standard numeric tests. We illustrate our work with 
reference to a standard reference model drawn from military avionics. 



1 Introduction 

To control an object means to influence its behaviour so as to achieve a desired 
goal. Control systems may be natural mechanisms, such as cellular regulation 
of genes and proteins by the gene control circuitry in DNA. They may be man- 
made - an early mechanical example was Watt’s steam governor but today 
most man-made control systems are digital, for example fighter aircraft or CD 
drives. In genomics we want to identify the control mechanism from observations 
of its properties: in engineering we want to solve the dual problem of constructing 
a system with certain properties. Traditionally, control is treated as a mathe- 
matical phenomenon, modelled by continuous or discrete dynamical systems. 
Numerical computation is used to test and simulate these models, for example 
Matlab is an industry standard in avionics. A largely separate process is then 
used in the implementation of such as continuous model as a digital (discrete) 
controller. 

Block diagrams are a standard engineering representation of dynamical sys- 
tems, obtained from a Laplace transform. In a recent paper [3] we added as- 
sertions about phase and gain of a signal to block diagrams and devised and 
implemented a simple Hoare logic. We were able to emulate mechanically engi- 
neers informal reasoning about phase and gain. We also prototyped symbolic, 
automated, very general alternatives to some standard numeric tests used in 
engineering design, and it is this work which forms the main result of this paper. 
We replace numeric plots with symbol manipulation in the computer algebra sys- 
tem Maple and the theorem prover PVS. This in turn exploited our Maple-PVS 
system [12], and GottliebsenOs PVS continuity checker [13]. 

Control engineering is a large subject: we intend to focus on those aspects 
which are to a control engineer fairly standard and widely used in practice [25] . 



E. Boiten, J. Derrick, G. Smith (Eds.): IFM 2004, LNCS 2999, pp. 21-35, 2004. 
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Optimal control assumes that a model of the system is available and one wants to 
optimise its behaviour, using the calculus of variations and so forth: for example 
pre-computing a desired flight-path for a spacecraft. Feedback control compen- 
sates for uncertainty in the model by using feedback to correct for deviations for 
desired behaviour: for example if the spacecraft strays off course. Models vary 
according to the application: for example differential equations are used when 
modelling a continuous signal, but these are replaced by difference equations 
when modelling a sampled signal as used in digital systems. In reasoning about 
such systems we are interested not only in the solutions, but in their properties. 
These include the time response, stability, frequency response and behaviour 
under perturbation. The time response considers features such as the time taken 
for a property of the system (e.g. the cruising speed of a car) to reach the desired 
value, and by how far it overshoots before settling at the desired value. Stability 
analysis considers whether the system will always settle into a steady state fol- 
lowing a change to the input (s). An output of an unstable system may increase 
out of control or oscillate. Frequency response considers the amplitude and phase 
shift of the output signal when the system is presented with a sinusoidal input. 
The analysis considers input signals with a range of frequencies. 

In practice systems are rarely linear: non-linear systems are generally treated 
OlocallyO by linearising at points of interest, but OglobalO behaviour is sub- 
ject of much research and raises subtle questions in differential and algebraic 
geometry. 

In OclassicalO control a Laplace transform is applied to a linear system 
to obtain a representation as a transfer function, a rational function over the 
complexes. Analysis of properties, such as frequency and response of the control 
system, is in terms of the position of its roots and poles in the complex plane. So 
called OmodernO control considers a state-space representation, which replaces 
a single differential equation with a system of simultaneous equations in the state 
variables, and analyses the system via properties of the eigenvalues of a related 
matrix. Both frameworks can be extended from SISO (single input) to MIMO 
(multiple input) systems. 

Block diagrams are often used to represent systems with feedback graphi- 
cally, for example in classical control a block diagram is a directed graph whose 
edges are labelled by rational functions over the complexes. They also allow more 
general representation of components described only by their input/output be- 
haviour. 

Software such as the widely used Matlrworks Simulink [21], the industry 
standard in avionics and automotive applications, supports numerical tests and 
simulations. A number of standard tests are used for prediction and analysis: 
for example the Nichols plot is a numerical test which investigates stability. It 
displays the steady state behaviour of a OclassicalO control system in terms of 
the phase and gain of a sinusoidal input. We shall see below how some of the 
control requirements of fighter aircraft are specified in terms of acceptable paths 
in this plot [26]. 

In practice man-made control systems are typically digital embedded soft- 
ware systems, which use sampled, rather than continuous time. These can be 
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modelled as discrete dynamical systems (difference equations), which again ad- 
mit a transform representation via the z-transform, and an analogous state-space 
representation, investigated as before using matrix algebra. The design of a dig- 
ital controller, for example in avionics applications, typically involves analysis 
as above in continuous time: it is then passed to a software team for implemen- 
tation as a discrete digital system. It has been suggested that this process is a 
likely source of error: indeed apparently ’’similar” continuous and discrete sys- 
tems may have very different stability properties. The ubiquity of such embedded 
controllers, for example in cars and domestic appliances, has led to increased in- 
terest in methods of generating assured code straight from a high level design 
[ 2 ]- 

The study of control in the context of computer science is an emerging area: 
we identify some strands of work which complement our own: 

— The most well developed is the field of hybrid systems, which models cer- 
tain control systems as automata with discrete transitions which are then 
amenable to model checking [20] and theoretical analysis [18]. Alur and Dill 
[5] introduced timed automata, state-transition diagrams annotated with 
timing constraints using finitely many real-valued clock variables which can 
be used to model discrete dynamical systems 

— In the 1970s Arbib and Manes [1] studied categorical models of linear con- 
trol: more recently various categories with feedback have been much studied, 
especially traced monoidal [16] categories, which are models for linear logic. 
These seem to obey similar algebraic laws to feedback diagrams, though as 
far as we know the connection has not been developed formally. Tourlas [14] 
has studied reasoning about general diagram languages. 

— Less attention has been paid to the classical dynamical systems represen- 
tations. Perhaps the closest foundational work is Edalat’s [9] extension of 
classical domain theory to analysis and dynamical systems. Tiwari [29] al- 
lows abstraction of dynamical systems to a level where model checking can 
be used. 

— Our own work on light formal methods for mathematical systems [6,7] was a 
precursor to this work: we devised an assertion language and lint-like checker 
for NAG Ltd’s AXIOM system. 

— The widespread use of Simulink suggests that effective formal verification 
techniques for block diagrams could have significant impact. The Clawz sys- 
tem of Artlran et al [2], developed for Qinetiq, is a first step: it translates 
discrete-time models, described using Simulink, into formal specifications in 
Z. A controller implementation in an Acla-like programming language can 
then be verified against these Z specifications using the ProofPower mech- 
anised proof assistant. Qinetiq used Clawz in a case study of the braking 
systems of the Eurofighter, and are addressing issues of concurrency in this 
framework using CSP/FDR. Mahony [23] has used similar ideas in his DOVE 
system. 

In a pilot study [3] we developed a Hoare-style logic and a verification con- 
dition generator for a restricted class of block diagrams, essentially those with 
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a tree structure. Hoare logics [17] were originally studied by Hoare, Floyd and 
others to give an axiomatic basis for programming, and continue to be used for 
a variety of applications, for example Java byte-code verification [24], As far as 
we know our work is the first to investigate Hoare-style logics for feedback sys- 
tems. We attached assertions to nodes in the diagram: the key observation was 
that phase and gain were compositional, and hence we could reason about them 
locally, and propagate our reasoning through the diagram to deduce proper- 
ties of a classical frequency-response analysis. Following Gordon’s approach [11] 
the logic was mechanised in the HOL98 theorem proving system, allowing goal- 
directed reasoning, machine assistance in the details of the proof, and automatic 
generation of verification conditions, the logical formulas that must ultimately 
be proved to justify an assertion in the Hoare logic. The verification conditions 
themselves are pure predicate logic formulas, that is, they do not involve the 
constructs of our logic. 

2 Design Requirements for Aerospace Applications 

As one might expect the design and verification of flight control laws, and their 
implementation in flight control systems of civilian or military aircraft, is a ma- 
ture technology involving many specialist teams in engineering companies and 
certification authorities - Pratt [26] provides a comprehensive account. Produc- 
ing a new plane typically takes around three years from the official program 
start to the first test flight, and can cost upwards of a billion dollars. The cus- 
tomer for a civilian aircraft might expect to get their first plane about a year 
after the first test flight: the flight test programme for military aircraft may 
be significantly longer as they are more likely to contain novel technologies to 
give enhanced performance, and these need to be tested across a greater range of 
highly dynamic missions, a wider flight envelope and varying payloads. The flight 
control algorithms represent between five and ten per cent of the flight control 
law (FCL) software on an aircraft, and this in turn represents around a quarter 
of the activity of the flight control system (FCS): the rest is associated with 
safety monitoring, redundancy management and so on. Typically development 
of the FCL and FCS follows the ”V-model”, moving down through the spec- 
ification of the aircraft, system, equipment and components to manufacturing 
and coding and then up through an integration path involving suitable valida- 
tion/verification at each level. Design engineers at the component level initially 
produce a control law for a (continuous) model of the airplane to meet certain 
design requirements: this is subsequently implemented as a digital controller and 
then incorporated in the design and test cycle for the full FCS. 

The controller is designed to obtain certain desired behaviours of the con- 
trolled system: for example we might want it to be stable, and to behave in a 
specified way, to within an error bound, in response to a given input function, 
such as a step function, or a sine wave. The desired behaviours constitute design 
requirements. For larger systems these may be expressed in two parts: a high 
level description of a property, for example ’’good flying qualities”, and a corre- 
sponding evaluation criterion, expressed as a precise mathematical property that 
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the controlled system is required to have to discharge the design requirement. It 
is these properties that are often expressed as showing that a particular curve 
avoids a partcular region, and discharged by plotting a graph. 

As an example we consider the Garteur HIRM (High Incidence Research 
Model) benchmark [10]. This was produced in the early nineties as a challenge 
problem in robust control: the design problem was to produce a control aug- 
mentation system for HIRM, an aircraft typical of modern combat aircraft. In 
general terms the aim of the flight control system is to give good handling qual- 
ities across the specified flight envelope and also provide robustness to unmod- 
elled plant dynamics, modelling uncertainties and variations in operating point 
within the flight envelope. Acceptable noise and disturbance rejection must also 
be demonstrated. 

In general simple approximate models are chosen so as to enhance under- 
standing of the principles of the design. The aircraft definition provides a con- 
tinuous model of the aircraft dynamics in terms of the flight conditions (which 
describe things such as aeroplane geometry, altitude, mass number etc), and 
the response of the aircraft to control inputs ( in terms of displacement, veloc- 
ity and acceleration). Models are also needed of atmospheric conditions and so 
forth. Thus for example HIRM is described in terms of 11 inputs (relating to 
taileron, canard and rudder deflections, throttle and wind), 16 states (velocities, 
roll pitch and yaw rates and angles, centre of gravity 1 etc) and 20 outputs. 

Initial design of the flight control laws is carried out against this reference 
model, to meet the high level design requirements. Pratt [26] provides a tlrro- 
rough account of many of these for modern fighter aircraft. We give two just 
examples to indicate some of the subtleties of design of modern fighter aircraft: 

— Good handling qualities are those that offer precise control in the various 
modes of operation of the aircraft, with low pilot workload. While the former 
can be estimated by from the model or judged by experiment, for the latter 
evaluation by pilots is typically used, and then correlated with parameters 
in aircraft response which the pilot uses in performing the task. Thus for ex- 
ample the phugoid is a low-frequency mode which causes oscillations in pitch 
and speed: this can be controlled by pilots but requires attention, so poor 
phugoid characteristics make for poor handling. Pilot induced oscillations 
are unwanted oscillations resulting from the pilots attempt to control the 
aircraft, and require subtle analysis particularly of unexpected behaviours 
of fly- by- wire systems. 

— aeroservoelasticity or structural coupling is the name given to the interac- 
tion between the flight control system of an aircraft and the oscillations of the 
airframe. The sensors of the flight control system detect not only the motion 
of the aircraft, which provides the required feedback to the control system, 
but also high frequency oscillations due to resonances of the airframe, which 
can feed into the control loop and cause instability. To solve this problem 
notch filters are introduced to attenuate the resonances. However these can 
also add a phase lag, which itself interferes with stability. Correcting the 

1 The centre of gravity may change as the plane burns fuel and ’’releases items” 
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phase lag with a phase advance filter introduces further coupling at high 
frequencies. Pratt [26] provides a detailed survey of how this design conflict 
was resolved for the Eurofighter, and the techniques used in the evaluation 
criteria. 

Notice that both these problems are made more challenging by the use of more 
complex automated control systems, lighter more flexible materials in the air- 
frame, and the need to take account of a variety of payloads. 

For the HIR.M model the design requirements comprise: 

— Control strategy 

— Pilot commands 

— Robustness considerations for the design envelope, modelling, measurement 
and hardware implementation 

— Robustness requirements 

— Performance requirements 

— Scheduling considerations 

and each requirement comes with a corresponding evaluation criterion. The eval- 
uation criteria comprise several hundred numeric tests in the form of response to 
specified inputs, generally expressed graphically. We expand below on one such 
test, the Nichols plot, which occurs in about half the criteria. 

3 Diagrams as Evaluation Criteria 

The Laplace transform provides an algebraic representation of a linear dynami- 
cal system as a transfer function G(S), that is a quotient of two polynomials in 
a complex variable s. Under this representation the input X(s) to G(s) is trans- 
formed to V(s) = G(s)X(s). Transfer functions provide the traditional block 
diagram representation used in Simulink. Thus for example the HIR.M rudder 
actuator has transfer function 

1 

1 + 0.0191401s + 0.000192367s 2 ' 

The behaviour under particular inputs is often represented graphically. For 
simplicity we describe only the ’’frequency response” analysis of such a system via 
Nichols plots. If a sine wave is input to a stable system it can be shown that the 
steady state output will also be a sine wave, of the same frequency u> as the input, 
but with different phase and amplitude. The difference between the output and 
input phases is called the ’’phase margin”, arg{G{Ioj)) = arg(Y(Iu>)/X(Iui)), 
and ratio of the output to the input amplitudes is called the ” gain margin” , that 
is \G(Iu>)\ = \Y{Iw)\/\X{Id)\. _ 

Thus a simple evaluation criterion for a design requirement might take the 
form 

— Phase margin greater than 40 degrees 

— Gain margin of G greater than 20 dB 
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The Nichols plot of G allows us to express more complex design requirements. 
It plots the phase against the gain in decibels for different values of the input 
frequency u>, and is given parametrically by 

x = arg{G{Iiot)) (1) 

y = 20ln(\G(Iu>t)\)/ln(10). (2) 




Fig. 1 . Handling requirements for HIRM model 



Thus one design requirement for the HIRM benchmark is a lengthy descrip- 
tion of ” acceptable handling qualities” that balance aircraft performance against 
pilot discomfort, and avoid pilot induced oscillations. The evaluation criteria are 
that a sequence of Nichols plots all lie in the region marked ’’good response” in 
Fig. 1. Other evaluation criteria used in HIRM require that various Nichols plots 
avoid a hexagonal exclusion region around ( — 7r , 0) . 

Other plots used in evaluation criteria include Bode and Nyquist plots in the 
frequency domain, and analysis of the response to ramp and step inputs in the 
time domain. Matlab [22] commands such as nicols, bode draw the respective 
plots of a given transfer function, and for small examples GUI tools allow the 
user to manipulate the plot to a required form, and obtain a modified form of 
the input that generates this output. 
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4 Computing with Real Numbers 

The methods above require us to discharge verification requirements which take 
the form of showing that a particular curve in R x R lies in a particular region 
bounded by straight lines, or more generally that a function is positive or con- 
tinuous in an interval. We briefly summarise the relevant methods from numeric 
and symbolic computation, and computational logic. 

Numerical methods. Numerical methods are the standard, and almost uni- 
versal, approach to computational support for analysis of control and dynamical 
systems, and in particular the discharge of such requirements. 

These are widely available through standard commercial libraries such as 
NAG and MatLab which generate numeric or graphical output, from which var- 
ious properties of the system may be inferred. In addition such systems can 
readily accommodate other inputs, for example from measurement devices, or 
other numerical procedures, such as curve fitting. For many problems, for ex- 
ample the investigation of chaotic phenomena, there are no alternative standard 
techniques. The main advantage of numerical systems is that they will always 
give an answer, and with sufficient user expertise are accepted as doing so suf- 
ficiently quickly and accurately, with established protocols for testing and error 
analysis. However the output, and properties derived from it, will be always be 
numeric and not analytic, and support for investigating other properties of the 
solution, for example continuity or behaviour under parameters, may be limited. 
Thus verifying a Nichols plot for a parameterisecl curve will involve drawing a 
series of plots for different values of the parameter. 

Symbolic computation. Symbolic computation systems, such as Maple, con- 
tain a variety of symbolic algorithms that might in principle be used discharge 
our verification requirements. 

We note that we cannot hope for a fully automatic test for an arbitrary 
function q to be positive in an interval [a, b } , as this is a version of the zero- 
constant problem and hence undecidable, even for q an expression generated by 
a variable x, the sin, exp and modulus functions [28] . There is much theoretical 
work on techniques for analysing questions of this kind for particular q, for 
example quantifier elimination, which is decidable for polynomial functions q, but 
can still be doubly exponential, and more effective methods such as cylindrical 
algebraic decomposition, CAD, which still become infeasible for complicated 
inequalities. Jirstrancl [18] experimented with CAD for polynomial differential 
equations with constraints, and solved some problems involving stationarity, 
stability, and curve following, but was only able to tackle small examples. 

Computer algebra systems test for analytic properties such as continuity, 
convergence or differentiability by using numeric or symbolic root-finding algo- 
rithms to find possible points of failure of the required property, which again 
reduces to the zero constant problem. While in principle parameters can be han- 
dled, computer algebra systems do not generally handle pre and side conditions 
well []. Consider the equation 
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y'(x) + y/{2^f[x — a)) = ln(6 — x) exp(— V x — a) (3) 

for which Maple returns 

y( x) = exp(— \Jx — a)(( x — 6)(ln(& — x) — 1) + C) (4) 

This supposed solution is only defined if x > a and x < b, so that if b < a it is 
not defined anywhere on the real line. Maple has produced this solution because 
the dsolve procedure, for finding a solution of an equation valid in an interval 
V, does does not check what the interval V might be, or the required conditions 
that functions are continuous on it. 

Computational logic and real number theorem proving. Computational 
logic means the use of a computer to produce a proof in some formal system. 
A variety of systems have been built, some motivated by experimentation in a 
particaular formal system, others by the need for increasingly complex practi- 
cal verification, especially hardware and distributed systems. We mention below 
other applications of computational logic to verification of control systems. Such 
systems may be hard to use, but the pay-off is that the user can be confident 
that the results that they produce are correct. SRI’s PVS [27] - prototype verifi- 
cation system - is based on sequent calculus and provides a collection of power- 
ful primitive inference mechanisms including propositional and quantifier rules, 
induction, rewriting, and decision procedures for linear arithmetic. The imple- 
mentations of these mechanisms are optimised for large proofs: there is support 
for proof strategies and a powerful brute force search mechanism called grind. 
PVS has a rich higher-order type system supporting overloading of operators, 
subtypes and dependent types, and mechanisms for parametric specifications. It 
has been widely used in applications, particularly aerospace work. 

As we saw in Section 1 computational logic has impacted control engineering: 
here we concentrate on those aspects useful in the discharge of design require- 
ments. 

Some form of real analysis has been implemented in many theorem provers, 
both because it forms the basis of much mathematics and, increasingly, because 
of its use in hardware verification: for example Harrison’s work on floating point 
verification [15]. PVS has a basic built-in theory of the reals: the axiomatisation 
is via the least upper bound principle, every non-empty set of reals bounded 
above has a least upper bound. Dutertre [8] extended this and developed a 
library for real analysis in PVS, including definitions and basic properties of 
convergence, limits, continuity and differentiation. Further development of real 
analysis in PVS is described in [13], where the transcendental functions were 
incorporated by defining the functions in terms of power series and constructing 
on top of the basic definitions a large lemma database of routine results about 
elementary functions, that is functions built up from rational functions of a 
variable x together with cos, sin, exp and log. Typical entries are: 

7 r 

sin( — ) = 1 cos(7r) = —1 

t r d 

sinfa;) = cos(— — x) — (sinfa;)) = cos(x) 

2 dx 
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Particularly useful for our work are procedures that attempt to check if a func- 
tion has a property in a closed interval [13]: typical properties are continuity, 
convergence and differentiability. The checker relies on results which follow the 
text-book development of continuity (sums of continuous functions are continu- 
ous and so on), augmented with our database and a collection of standard results 
about the continuity of elementary functions. 

The method used for this checking is what one might call the High School 
method. It is based on the theorems that the constant functions and the identity 
function are continuous everywhere, and that well-founded combinations using 
the following operators are also continuous: addition, subtraction, multiplication, 
division, absolute value and function composition. Also, the functions exp, cos, 
sin and tan are continuous everywhere in their domains. The checker can be used 
to check the continuity and limiting behaviour of functions such as 

e * 2 +|i-d or _ 7T _ i + n * gi-cosfx). 

As continuity is undecidable [4], this will not always work, however for many 
examples it is sufficient. Note also that if a proof fails using the checker we 
can always go back and prove the result from first principles and add it to 
the database. The evolving nature of the database makes it hard to provide 
efficiency measures. At first sight it might appear that using a computational 
logic engine for such symbolic analysis gives one no advantage over a computer 
algebra system, and the considerable disadvantage that it is very much harder 
to use. However as we have seen computer algebra systems have a number of 
disadvantages, and computational logic engines like PVS have the advantage 
that the results they produce are correct and unambiguous. Our methods may 
fail if the lemma database does not contain an appropriate result: however if 
they report success this will always be justified by a proof, rather than, as in a 
computer algebra system, failure of a root finding algorithm or similar. 



Maple-PVS. Our Maple-PVS system [12] combines symbolic computation and 
computational logic by providing restricted invocation of PVS from Maple to 
perform the checks we describe above. These are called from Maple by a simple 
pipe-lined interface. As well as direct calls from Maple to verify continuity and so 
on, we are able to build these checks into other Maple procedures. For example, 
it is straightforward to write a harness for a Maple routine to solve differential 
equations which checks the validity of the pre-conditions for the routine to be 
correct. 

5 Symbolic Diagram Testing with Maple-PVS 

We described above how classical control engineering gives rise to design require- 
ments expressed geometrically, typically in the form of plots such as the Nichols 
plots. In this section we show how to discharge these requirements automatically 
in some cases using symbolic computation and computational logic embedded 
in our Maple-PVS system. 
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Our approach is based in the following simple idea. Tests based on such plots 
concern showing that a given curve y = f(x) is bounded above (or below) by a 
given line y = g(x) in an interval [a, 6], or equivalently that 

Mx e [a, b],g(x) - f(x) > 0. (5) 

The following two theorems each provide a sufficient condition for the inequality 
to hold which is readily verified symbolically for certain lines and curves. 

Theorem 1. Given real-valued functions f,g defined throughout an interval 
[a, b] and satisfying 

1. g is linear in [a, b } 

2. f(x) is continuous and twice differentiable in [a, b] 

3. f(x) is monotonic increasing and concave in [a, b\, ie f (x) > 0 and f (x) is 
monotonically decreasing in [a, b], ie f (x) > 0 and f ( x ) < 0 in [a, b]. 

4 ■ g(b) > m 
5. g\b)<f\b) 

then f(x) < g(x ) throughout the region [a, b}. 

The proof of this is straightforward. Let g(x) = px + g. The continuous function 
g(x) — f(x) attains its maximum and minimum values in an interval at endpoints 
or at zeroes of p — f (x). Now for any x in [a, b] we have p — f (x) < p — f (b) = 
g (6) — / (6) < 0, so the minimum value of g(x) — f(x) is either g(b) — f(b) > 0, 
or g(a) - f(a) > g(b) - f(b) + (f(b) - p)(b-a)> 0. 

Theorem 2. Given real-valued functions f,g defined throughout an interval 
[a, b] and satisfying 

1. g is linear in [a, b } 

2. f(x) is continuous and twice differentiable in [a, b] 

3. f(x) is monotonic increasing and convex in [a, b] , ie f (x) > 0 and f (x) is 
monotonically increasing in [a, b\, ie f (x) > 0 and f (x) > 0 in [a, b]. 

4 ■ g(b) > f(b) 

5. g(a) > /(a) 

then f{x) < g(x) throughout the region [a, b]. 

Similar results hold for f(x) monotonic decreasing, and with a and b inter- 
changed. 

Theorem 1 ensures the correctness of the following test for condition (1): 

1. compute the verification conditions (i)-(v) above 

2. verify that conditions (i)-(v) hold 

For any g(x) linear and f(x) continuous and twice differentiable in [a, b], we 
can partition [a, b } into intervals determined by the zeroes and points of inflection 
of g(x) — /( x) and g (x) — f (x), and hence apply one or other of these theorems 
in each interval to determine whether f is bounded above by g throughout. 
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In the case of the Nichols plot of a transfer function G(s), which is a rational 
function (ie a quotient of two polynomials), the curve y = f{x) will be given 
parametrically by 



x = arg(G(Iuit)) (6) 

y = 20Zn(|G(/wf)|)/Zn(10) (7) 

and its derivatives / ( x), f (x) will be quotients of polynomials in cos, sin and 

x. 

We carried out a prototype implementation of the test using our Maple- 
PVS system described above. Maple readily computes the verification conditions, 
which require computing and simplifying derivatives. PVS is used to discharge 
them, using its tests for continuity and inequality of elementary functions. 



Example 

As an example consider the transfer function 

G(s) = k.(s 2 + 2cs + d)^ 1 (8) 

and Nichols plot in the region [—7 r, — 7r / 2] . This is the graph of |G(/u>)| against 
20logio\(tan~ 1 (Im(G(Iw) /Re(G(Iw)))\, given parametrically by 

x := arg(fc.(— t 2 + 2 let + d )^ 1 ) 
y := (20 In \ k.{—t 2 + 2/cf + d ) _1 ) | /^n(10)). 



(9) 

(10) 





Design Verification for Control Engineering 



33 



Then, as an example, Condition (iii) requires us to calculate dy/dx and show 
positive in [— 7r, — 7 t/ 2]. Maple shows 

dy/dx = 20 sin(x)(—c Q + c 2 cos(x ) + d 2 cos(x)) / Q / (c cos(x ) + Q/ln(10) (11) 
where 



Q = ( c 2 cos{x ) 2 + d 2 sin(x) 2 ) < - 1 ^ 2 \ (12) 

In this case the PVS test that dy/dx is positive in the desired region follows the 
usual informal human reasoning - parse the expression into a quotient of sums 
of products, use the lemma database to identify the sign of each component - for 
example sin and cos are both negative in the given interval - and hence deduce 
the sign of the products, then the sums, then the quotient. 

It is hard to provide a complexity or timing analysis of our method, since it 
is built on top of an evolving lemma database. For the kind of applications we 
consider the inputs are not random, but typically consist of a large number of 
tests in rather similar format - for example Nichols plots are usual computed over 
the interval [— tt, — 7t/2], and in the HIRM model nearly all satisfy the conditions 
of Theorem 1. Hence it is worthwhile optimising the system by extending the 
lemma database as required. Our method is related to what is called, in computer 
graphics, the method of Lipschitz bounds, devised by Kalra and Barr [19] to 
handle ray-tracing as a technique for visualising implicit surfaces. 

6 Analysis 

We are aiming to find automated symbolic methods of design testing, to replace 
the use of numerical graph plots which are verified by inspection. 

We prototyped our method for Theorem 1 and another similar test, and 
performed the necessary computations in Maple and PVS. Maple can readily 
provide the support that we need to compute derivatives, simplify and so on. 
PVS contains definitions and properties of elementary functions and likewise 
provides much of what we need, and the necessary material is under constant 
development, particularly in support of NASA’s verification work on air traffic 
control algorithms. 

There are a number of other symbolic computation and theorem proving 
technologies which could be used to implement this approach to design testing - 
in particular it would be fairly straightforward to eliminate the dependency on 
Maple altogether and use a rewrite engine to compute and simplify derivatives. 
Longer term there is no obstacle in principle to embedding the whole process as 
an automated call from other engines, like Simulink. 

Note that unlike numeric tests our methods are not samples, but provide 
verification, subject to the correctness of the underlying Maple-PVS implemen- 
tation, for all values in the interval. We hope to be able to use similar methods 
for robust control, where we will need to consider parameterised curves, and to 
extend to non-linear systems. Current techniques like Bode and Nichols plots are 
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a heritage of the pre-computer days when they really were plotted on graph pa- 
per. However the availability of methods like ours encourages speculation about 
other design verification methods which while impossible to plot and eyeball may 
be susceptible to symbolic verification. 
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Abstract. Forte is a formal verification system developed by Intel’s 
Strategic CAD Labs for applications in hardware design and verification. 
Forte integrates model checking and theorem proving within a functional 
programming language, which both serves as an extensible specification 
language and allows the system to be scripted and customized. The latest 
version of this language, called reFF c *, has quotation and antiquotation 
constructs that build and decompose expressions in the language itself. 
This provides combination of pattern-matching and reflection features 
tailored especially for the Forte approach to verification. This short pa- 
per is an abstract of an invited presentation given at the International 
Conference on Integrated Formal Methods in 2004, in which the philos- 
ophy and architecture of the Forte system are described and an account 
is given of the role of reFIP°t in the system. 



1 The Forte Verification Environment 

Forte [17] is a formal verification environment that has been very effective on 
large-scale, industrial hardware verification problems at Intel [10,11,12,15]. The 
Forte system combines several model checking and decision algorithms with 
lightweight theorem proving in higlrer-order logic. These reasoning tools are 
tightly integrated within a strongly-typed, higher-order functional programming 
language called FL. This allows the Forte environment to be customised and 
large proof efforts to be organized and scripted effectively. FL also serves as an 
expressive language for specifying hardware behaviour. 

Model checking using symbolic trajectory evaluation (‘STE’) lies at the core 
of the Forte environment. STE [16] can be viewed as a hybrid between a sym- 
bolic simulator and a symbolic model checker. As a simulator, STE can com- 
pute symbolic expressions giving outputs as a function of arbitrary inputs. As a 
model checker, it can automatically check the validity of a simple temporal logic 
formula — computing an exact characterization of the region of disagreement if 
the formula is not unconditionally satisfied. These features provide a seamless 
connection between simulation and verification as well as excellent feedback on 
failed proof attempts — two key elements of an effective usage methodology for 
large-scale formal verification [10,17]. 
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STE is a particularly efficient model checking algorithm, in part because it 
has a very restricted temporal logic. But STE, like any model checker, still has 
very limited capacity. Forte therefore complements STE with a higher-order logic 
theorem prover of similar design to the HOL system [6] . Theorem proving bridges 
the gap between big, practically-important verification tasks and tractable model 
checking problems. The Forte philosophy is to have as thin a layer of theorem 
proving as possible, since using this technology is still difficult. But case studies 
have shown that a surprising amount of added value can be gained from even 
very simple (mathematically ‘shallow’) theorem proving. 

The Forte approach is to tightly integrate model checking and theorem prov- 
ing within the single framework of a functional programming language and its 
runtime system. A highly engineered implementation of STE is built into the 
core of the language, with many entry points provided as user-visible functions. 
Two key aspects of this architecture are that it is a ‘white-box’ integration of 
model checking and theorem proving and that functional programming plays a 
central role in scripting verification efforts. 



2 The reFB c t Functional Language 

The successor to FL for future generations of Forte is a new functional language 
called reFIS-rt [7] . The reFE c t language is strongly typed and similar to ML [8] , 
but has quotation and antiquotation constructs like those in LISP but in a typed 
setting. This provides combination of pattern-matching and reflection tailored 
especially for the Forte approach to verification. In what follows, a brief sketch 
is given of the motivation for the design of these features. 

In higher-order logic theorem provers like HOL the logical ‘object language’ 
in which reasoning is done is embedded as a data-type in the (functional) meta- 
language used to control the reasoning. This makes the various term analysis 
and transformation functions required by a theorem prover straightforward to 
implement. But separating the object-language and meta-language also causes 
duplication and inefficiency. Many theorem provers, for example, need to include 
special code for efficient execution of object-language expressions [2,3]. 

In reFE°t , the data-structure used by the underlying language implemen- 
tation to represent syntax trees is made available as a data-type within the 
language itself. Functions on that data-structure, such as evaluation, are also 
made available. This approach retains all the term inspection and manipulation 
abilities of a conventional theorem prover while borrowing an efficient execution 
mechanism from the meta-language implementation. 

It also builds reflection [9] into the logic of the theorem prover. In systems like 
HOL, higher order logic is constructed along the lines of Church’s formulation 
of simple type theory [5], in which the logic is defined on top of the A-calculus. 
Defining a logic on top of reFE°t in the same way gives a higher-order logic that 
includes the reFE c t reduction rules as well as certain reflection inference rules. 

These reflection capabilities allow Forte to make a logically principled connec- 
tion between theorems in higher order logic and the results of invoking a model 
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checker. A similar mechanism called lifted-FL [1] was available in earlier ver- 
sions of Forte, but reFE provides much richer possibilities. For example, one 
can use quantifiers to create a bookkeeping framework that cleanly separates 
logical content from model-checking control parameters. 

In addition to serving as a meta-language for theorem proving, functional pro- 
gramming languages have often been used to describe the structure of hardware 
designs. Notable examples include work done in Haskell [4,14] and LISP [13]. 
A key capability exploited by such work is simulation of hardware designs by 
program execution. In Forte, however, we also wish to do various operations on 
the abstract syntax of models written in the language, as well as straight simula- 
tion. For example, we wish to implement and possibly even verify circuit design 
transformations [20]. ReFE makes this a built-in part of the language. 

The reFE°t language can been seen as an application-specific contribution 
to the field of meta-programming [18]. Unlike most meta-programming systems, 
however, the target applications for reFE°t in Forte give intensional analysis a 
primary role in the language. Its design is therefore somewhat different from 
staged functional languages like MetaML [21] and Template Haskell [19], which 
are aimed more at program generation and the control and optimization of eval- 
uation. 
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Abstract. In their Unifying Theories of Programming (UTP), Hoare & 
He use the alphabetised relational calculus to give denotational seman- 
tics to a wide variety of constructs taken from different programming 
paradigms. A key concept in their programme is the design : the familiar 
precondition-postcondition pair that describes the contract between a 
programmer and a client. We give a tutorial introduction to the theory 
of alphabetised relations, and its sub-theory of designs. We illustrate the 
ideas by applying them to theories of imperative programming, including 
Hoare logic, weakest preconditions, and the refinement calculus. 



1 Introduction 

The book by Hoare & He [6] sets out a research programme to find a common 
basis in which to explain a wide variety of programming paradigms: unifying 
theories of programming (UTP). Their technique is to isolate important language 
features, and give them a denotational semantics. This allows different languages 
and paradigms to be compared. 

The semantic model is an alphabetised version of Tarski’s relational calculus, 
presented in a predicative style that is reminiscent of the schema calculus in 
the Z [14] notation. Each programming construct is formalised as a relation 
between an initial and an intermediate or final observation. The collection of 
these relations forms a theory of the paradigm being studied, and it contains 
three essential parts: an alphabet, a signature, and healthiness conditions. 

The alphabet is a set of variable names that gives the vocabulary for the 
theory being studied. Names are chosen for any relevant external observations 
of behaviour. For instance, programming variables x, y, and z would be part of 
the alphabet. Also, theories for particular programming paradigms require the 
observation of extra information; some examples are a flag that says whether the 
program has started (okay); the current time (clock); the number of available 
resources (res); a trace of the events in the life of the program (tr); or a flag that 
says whether the program is waiting for interaction with its environment (wait). 
The signature gives the rules for the syntax for denoting objects of the theory. 
Healthiness conditions identify properties that characterise the theory. 

Each healthiness condition embodies an important fact about the computational 
model for the programs being studied. 
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Example 1 (Healthiness conditions). 

1. The variable clock gives us an observation of the current time, which moves 
ever onwards. The predicate B specifies this. 

B = clock < clock' 

If we add B to the description of some activity, then the variable clock 
describes the time observed immediately before the activity starts, whereas 
clock ' describes the time observed immediately after the activity ends. If we 
suppose that P is a healthy program, then we must have that P =$■ B. 

2. The variable okay is used to record whether or not a program has started. 
A sensible healthiness condition is that we should not observe a program’s 
behaviour until it has started; such programs satisfy the following equation. 

P = ( okay => P) 

If the program has not started, its behaviour is not described. □ 

Healthiness conditions can often be expressed in terms of a function (j> that makes 
a program healthy. There is no point in applying </> twice, since we cannot make 
a healthy program even healthier. Therefore, 4> must be idempotent: P = <j)(P ); 
this equation characterises the healthiness condition. For example, we can turn 
the first healthiness condition above into an equivalent equation, P = P A B, 
and then the following function on predicates ands = AI • f A B is the 
required idempotent. 

The relations are used as a semantic model for unified languages of speci- 
fication and programming. Specifications are distinguished from programs only 
by the fact that the latter use a restricted signature. As a consequence of this 
restriction, programs satisfy a richer set of healthiness conditions. 

Unconstrained relations are too general to handle the issue of program ter- 
mination; they need to be restricted by healthiness conditions. The result is 
the theory of designs, which is the basis for the study of the other program- 
ming paradigms in [6]. Here, we present the general relational setting, and the 
transition to the theory of designs. 

In the next section, we present the most general theory of UTP: the alpha- 
betised predicates. In the following section, we establish that this theory is a 
complete lattice. Section 4 discusses Hoare logic and weakest preconditions. Sec- 
tion 5 restricts the general theory to designs. Next, in Section 6, we present an 
alternative characterisation of the theory of designs using healthiness conditions. 
After that, we rework the Hoare logic and weakest preconditions definitions; we 
also outline a novel formalisation of Morgan’s calculus based on designs. Finally, 
we conclude with a summary and a brief account of related work. 



2 The Alphabetised Relational Calculus 

The alphabetised relational calculus is similar to Z’s schema calculus, except that 
it is untyped and rather simpler. An alphabetised predicate (P, Q, . . . , true) is an 
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alphabet-predicate pair, where the predicate’s free variables are all members 
of the alphabet. Relations are predicates in which the alphabet is composed 
of undecoratecl variables (x, y, z, . ..) and dashed variables (x', a', ■■■); the 
former represent initial observations, and the latter, observations made at a 
later intermediate or final point. The alphabet of an alphabetised predicate P is 
denoted aP, and may be divided into its before-variables ( inaP ) and its after- 
variables ( outaP ). A homogeneous relation has outaP = inaP' , where inaP' 
is the set of variables obtained by dashing all variable in the alphabet inaP. A 
condition (b, c, d, . . . , true) has an empty output alphabet. 

Standard predicate calculus operators can be used to combine alphabetised 
predicates. Their definitions, however, have to specify the alphabet of the com- 
bined predicate. For instance, the alphabet of a conjunction is the union of the 
alphabets of its components: a(P A Q) = aP U aQ. Of course, if a variable is 
mentioned in the alphabet of both P and Q, then they are both constraining 
the same variable. 

A distinguishing feature of UTP is its concern with program development, 
and consequently program correctness. A significant achievement is that the 
notion of program correctness is the same in every paradigm in [6]: in every 
state, the behaviour of an implementation implies its specification. 

If we suppose that aP = {a, b, a', &'}, then the universal closure of P is 
simply V a, b, a', b' • P, which is more concisely denoted as [P]. The correctness 
of a program P with respect to a specification S is denoted by S E P (S is 
refined by P), and is defined as follows. 

S CP iff [P=>S] 

Example 2 (Refinement). Suppose we have the specification x 1 > x A y' = y, 
and the implementation x' = x + 1 A y' = y. The implementation’s correctness 
is argued as follows. 

x' > x A y' = y E x' = x + 1 A y' = y [definition of C/ 

= [x' = x + lAy' = y=>x' >x Ay 1 = y] [universal one-point rule, twice] 
= [x + l>xAy = y] [arithmetic and reflection] 

= true 

And so, the refinement is valid. □ 

As a first example of the definition of a programming constructor, we consider 
conditionals. Hoare & He use an infix syntax for the conditional operator, and 
define it as follows. 

P <1 b t> Q = (b A P) V (-i b A Q) if ab C aP = aQ 

a(P <1 b t> Q) = aP 

Informally, P <J b t> Q means P if b else Q. 
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The presentation of conditional as an infix operator allows the formulation of 
many laws in a helpful way. 



LI P <3 b > P = P idempotence 

L2 P<\b>Q = Q<\^b>P symmetry 

L3 (P<\b>Q)<\c>R=P<\bAc>(Q<\c>R) associativity 

L4 P <3 b > (Q <3 c > R) = (P <1 b t> Q) <3 c > (P <3 b > R) distributivity 

L5 P < I true > Q = P = Q <3 false \> P unit 

L6 P <b>{Q <b> R) = P <b> R unreachable branch 

L7 P<lbt>(P<ict>Q) = P<lb\/ct>Q disjunction 

L8 (P 0 Q) <3 b t> (R © S) = (P <1 b [> R) © (Q <3 b > S) interchange 



In the Interchange Law (L8), the symbol 0 stands for any truth- functional op- 
erator. 

For each operator, Hoare & He give a definition followed by a number of 
algebraic laws as those above. These laws can be proved from the definition. As 
an example, we present the proof of the Unreachable Branch Law ( L6 ). 

Example 3 (Proof of Unreachable Branch (Lb)). 



(P < 6 > (Q < b > R)) 

= ((Q < b > R) < -> b > P) 

= (Q <3 b A -i b > (R <3 —>bt> P)) 
= (Q < I false t> (R < -> b t> P)) 

= (R < -i.b > P) 

= (P <\b\> R) 



[L2] 

[L3] 

[propositional calculus] 
[L5] 
[L2] 



Implication is, of course, still the basis for reasoning about the correctness 
of conditionals. We can, however, prove refinement laws that support a compo- 
sitional reasoning technique. 

Law 1 (Refinement to Conditional) 

P C (Q < b > R) = (P C b A Q) A (P C - b A R) □ 



This result allows us to prove the correctness of a conditional by a case analysis 
on the correctness of each branch. Its proof is as follows. 

Proof of Law 1 . 

P C (Q<\b>R) [definition ofU] 

= [(Q < b> R) => P] [definition of conditional] 

= [ 6 A QV-<bAR=>P] [propositional calculus] 

= [bAQ=>P]A[-<bAR=>P] [definition of C, twice] 

= (P Qb A Q) A (P b A R) 



□ 
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A compositional argument is also available for conjunctions. 

Law 2 (Separation of Requirements) 

((P A Q) C R) = (P C R) A (Q C R) □ 

We can prove that an implementation satisfies a conjunction of requirements by 
considering each conjunct separately. The omitted proof is left as an exercise for 
the interested reader. 

Sequence is modelled as relational composition. Two relations may be com- 
posed, providing that the output alphabet of the first is the same as the input 
alphabet of the second, except only for the use of dashes. 

P(v') ; Q(v) = 3 vo • P(v o) A Q(v o) if outaP = inaQ' = {V} 

ina{P{v') ; Q(v)) = inaP 
outa(P(v') ; Q{v )) = outaQ 

Composition is associative and distributes backwards through the conditional. 
LI P ; (Q ; R) = (P ; Q) ; R associativity 

L2 (P <1 b t> Q) ; R = ((P ; R) <\ b > (Q ; R)) left distribution 

The simple proofs of these laws, and those of a few others in the sequel, are 
omitted for the sake of conciseness. 

The definition of assignment is basically equality; we need, however, to be 
careful about the alphabet. If A = {x, y, . . . ,z} and ae C A, where ae is the set 
of free variables of the expression e, the assignment x :=a e of expression e to 
variable x changes only x’s value. 

x :=a e = (x' = e A y’ = y A • • • A z' = z) 
a(x :=a e) = A U A' 

There is a degenerate form of assignment that changes no variable: it’s called 
“skip”, and has the following definition. 

I A = (v' = v) if A = {«} 

aI A = Al) A 1 

Skip is the identity of sequence. 

L5 P ; I a p = P = I a p ; P unit 

We keep the numbers of the laws presented in [6] that we reproduce here. 

In theories of programming, nondeterminism may arise in one of two ways: ei- 
ther as the result of run-time factors, such as distributed processing; or as the 
under-specification of implementation choices. Either way, nondeterminism is 
modelled by choice; the semantics is simply disjunction. 

P n Q = P V Q if aP = olQ 

a(P n Q) = aP 

The alphabet must be the same for both arguments. 
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The following law gives an important property of refinement: if P is refined by 
Q , then offering the choice between P and Q is immaterial; conversely, if the 
choice between P and Q behaves exactly like P, so that the extra possibility of 
choosing Q does not add any extra behaviour, then Q is a refinement of P. 

Law 3 (Refinement and Nondeterminism) 

PQQ = (PnQ = P) □ 



Proof. 

P n Q = P 

= (P n Q c P) a (P c P n Q) 
= [P => p n Q) a[p n Q => P] 
= [P => P V Q] A[P V Q => P] 
= true A [P V Q => P] 

= [Q^P] 

= PQQ 



[antisymmetry] 
[definition of\Z, twice] 
[definition of n, twice] 
[propositional calculus] 
[propositional calculus] 
[definition of\— ] 
□ 



Another fundamental result is that reducing nondeterminism leads to refinement. 



Law 4 (Thin Nondeterminism) 

p n Q c P □ 

The proof is immediate from properties of the propositional calculus. 

Variable blocks are split into the commands var x, which declares and intro- 
duces x in scope, and end x , which removes x from scope. Their definitions are 
presented below, where A is an alphabet containing x and x' . 
var x = (3x»Ia) a(varx) = A \ {x} 

end x = (3 x'»Ia) a(endx) = A \ {x'} 

The relation var x is not homogeneous, since it does not include x in its alphabet, 
but it does include x' \ similarly, end x includes x, but not x ' . 

The results below state that following a variable declaration by a program Q 
makes x local in Q; similarly, preceding a variable undeclaration by a program 
Q makes x' local. 

( var x ; Q ) = ( 3 x • Q ) 

( Q ; end x ) = ( 3 x' • Q ) 

More interestingly, we can use var x and end x to specify a variable block. 

(var x ; Q ; end x ) = ( 3 x, x' • Q ) 

In programs, we use var x and end x paired in this way, but the separation is 
useful for reasoning. 
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The following laws are representative. 

L6 ( var x ; end x ) = I 
L8 ( x := e ; end x ) = ( end x ) 

Variable blocks introduce the possibility of writing programs and equations like 
that below. 

( var x ; x := 2 * y ; w := 0 ; end x ) 

= ( var x ; x := 2 * y ; end x ) ; w := 0 

Clearly, the assignment to w may be moved out of the scope of the the declara- 
tion of x , but what is the alphabet in each of the assignments to wl If the only 
variables are w, x, and y, and suppose that A = {w, y, w', y'}, then the assign- 
ment on the right has the alphabet A; but the alphabet of the assignment on 
the left must also contain x and x', since they are in scope. There is an explicit 
operator for making alphabet modifications such as this: alphabet extension. If 
the right-hand assignment is P = w :=a 0, then the left-hand assignment is 
denoted by P+ x . 

P +x = P A x' = x for x,x'^aP 

a(P+ x ) = aPU{x,x'} 

If Q does not mention x, then the following laws hold. 

LI var x ; Q +x ; P ; end x = Q ; var x ; P ; end x 

L2 var x ; P ; Q+ x ; end x = var x ; P ; end x ; Q 

Together with the laws for variable declaration and undeclaration, the laws of 
alphabet extension allow for program transformations that introduce new vari- 
ables and assignments to them. 

3 The Complete Lattice 

The refinement ordering is a partial order: reflexive, anti-symmetric, and tran- 
sitive. Moreover, the set of alphabetised predicates with a particular alphabet 
A is a complete lattice under the refinement ordering. Its bottom element is de- 
noted _I_ A , and is the weakest predicate true; this is the program that aborts, and 
behaves quite arbitrarily. The top element is denoted T A , and is the strongest 
predicate false; this is the program that performs miracles and implements every 
specification. These properties of abort and miracle are captured in the following 
two laws, which hold for all P with alphabet A. 

LI _I_ A C P bottom element 

L2 PC T a top element 

The least upper bound is not defined in terms of the relational model, but by 
the law LI below. This law alone is enough to prove laws L1A and LIB , which 
are actually more useful in proofs. 
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LI P C (n S) iff (PCI for all X in S) unbounded nondeterminism 
L1A (n S) Cf X for all X in S lower bound 

LIB if P C X for all X in S , then P C (n 5) greatest lower bound 

These laws characterise basic properties of least upper bounds. 

A function F is monotonic if and only if PC Q => F(P) Q F(Q). Operators 
like conditional and sequence are monotonic; negation and conjunction are not. 
There is a class of operators that are all monotonic. 

Example ) (Disjunctivity and monotonicity) . Suppose that P C Q and that © 
is disjunctive, or rather, R 0 (S n T) = (R © S) n (R 0 T). From this, we can 
conclude that P 0 R is monotonic in its first argument. 

P © R [assumption (P C Q) and Law 3] 

= (Pn Q) © R [assumption (Q disjunctive)] 

= (P 0 R) n (Q © R.) [thin nondeterminism] 

C QQR 

A symmetric argument shows that P© Q is also monotonic in its other argument. 
In summary, disjunctive operators are always monotonic. The converse is not 
true: monotonic operators are not always disjunctive. □ 

Since alphabetised relations form a complete lattice, every construction de- 
fined solely using monotonic operators has a fixed-point. Even more, a result by 
Tarski says that the set of fixed-points form a complete lattice themselves. The 
extreme points in this lattice are often of interest; for example, T is the strongest 
fixed-point of X = P ; X, and T is the weakest. 

The weakest fixed-point of the function F is denoted by p F, and is simply 
the greatest lower bound (the weakest) of all the fixed-points of F. 

pF = H{X | F(X) Cl} 

The strongest fixed-point isF is the dual of the weakest fixed-point. 

Hoare & He use weakest fixed-points to define recursion. They write a re- 
cursive program as pX • C(X), where C(X) is a predicate that is constructed 
using monotonic operators and the variable X. As opposed to the variables in 
the alphabet, X stands for a predicate itself, and we call it the recursive vari- 
able. Intuitively, occurrences of X in C stand for recursive calls to C itself. The 
definition of recursion is as follows. 

pX»C{X) = pF where F = A X • C(X) 

The standard laws that characterise weakest fixed-points are valid. 

LI p F C Y if F(Y) C Y weakest fixed-point 

L2 [F(pF)=pF] fixed-point 

LI establishes that pF is weaker than any fixed-point; L2 states that pF is 
itself a fixed-point. From a programming point of view, L2 is just the copy rule. 




48 



J. Woodcock and A. Cavalcanti 



Proof of LI. 

F{Y) C Y 

= Y e {X | F(X) OX} 

=> n{X I F(X) oxjo Y 

= p F O Y 

Proof of L2. 

pF = F(pF) 

= pF O F(pF) A F(pF) C pF 
4= F(F{pF)) O F{pF) A F(pF) O fiF 
4= F(pF) C pF 
= F(pF) O 0\{X | F(X) OX} 

4= VI G {X | F{X) OX} • F{pf) O X 
= VI» F(X) Cl4 F(/xF) O X 
4=VI. F(X) F(pF) O F(X) 

<^VI* F(X) OX => iiF OX 
= true 



[set comprehension] 
[lattice law L1A] 
[definition of pF] 
□ 



[mutual refinement] 
[fixed-point law LI] 
[F monotonic] 
[definition] 
[lattice law LIB] 
[comprehension] 
[transitivity of O] 
[F monotonic] 
[fixed-point law LI] 
□ 



The while loop is written b* P: while b is true, execute the program P. This 
can be defined in terms of the weakest fixed-point of a conditional expression. 

b*P = pX • ((P ; X) < b > I) 



Example 5 (Non-termination). If b always remains true, then obviously the loop 
b * P never terminates, but what is the semantics for this non-termination? 
The simplest example of such an iteration is true * I, which has the semantics 
pX • X. 



pX • X 

= H{Y\ (A X •X)(Y) O Y } 
= n{ Y I Y C Y } 

= n{ Y | true } 

= _L 



[definition of least fixed-point] 
[function application] 
[relexivity of O] 
[property of 0\] 
□ 



A surprising, but simple, consequence of Example 5 is that a program can 
recover from a non-terminating loop! 

Example 6 (Aborting loop). Suppose that the sole state variable is x and that c 
is a constant. 
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(b * P); x := c 
= _L; x := c 
= true ; x := c 
= true; x' = c 
= 3 xo • true Ai' = c 
= x' = c 
= x := c 



[Example 5] 
[definition of - L] 
[definition of assignment] 
[definition of composition] 
[predicate calculus] 
[definition of assignment] 
□ 



Example 6 is rather disconcerting: in ordinary programming, there is no recov- 
ery from a non-terminating loop. It is the purpose of designs to overcome this 
deficiency in the programming model; we return to this in Section 5. 



4 Theories of Program Correctness 

In this section, we apply the theory of alphabetised relations to two key ideas in 
imperative programming: Hoare logic and the weakest precondition calculus. 

4.1 Hoare Logic 

Hoare logic provides a way to decompose the correctness argument for a pro- 
gram. The Hoare triple p {Q} r asserts the correctness of program Q against 
the specification with precondition p and postcondition r: 

p{Q}r = (p => r') C Q 

The logical rules for Hoare logic are very famous. We reproduce some below. 



LI 


if p {Q} r and p { Q} s then p { Q} (r A s) 




L3 


if p{Q}r then (pA?){Q}(rVs) 




L4 


r(e) {x := ej r(x) 


assignment 


L6 


if V { Qi} s and s { Q- 2 } r then p { Q 1 ; Q 2 } r 


sequence 


L8 


if ( b A c) {<5} c then c { vX • (Q ; X) <] b t> 1 } (- 


-> b A c) iteration 


L9 


false { Q } r and p { Q } true and p {false} false and 


p {l}p 



The proof rule for iteration uses strongest fixed-points. The implications of this 
are explained below. First, we present a proof for the rule. 

Proof of L8. Suppose that (b A c) {Q} c, and let Y be the overall specification, 
so that Y = c => -i b' A c' . 

c { vX • ( Q ; X) < 6 > I } (-i 6 A c) 

= Y C vX • (Q ; X) < 6 > I 



[definition of Hoare triple] 
[strongest fixed-point LI] 
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<= F C (Q ; 7) < 6 > I [refinement to conditional (Example 1)] 

= (YQ(bAQ); F)A(yCiiAI) [definition of C/ 

= ( y C (6 A Q) ; y) A h J A 14 i 1 A c , )l 



= ( y E (6 A (?) ; y ) A true 
= c { & A <5 ; y } (- & A c) 

4= ( c { & A <5 }c)A(c{c=4“ ^ • b' 

= true 



[propositional calculus & definition of I] 
[definition of Hoare triple] 
[sequential composition (Hoare L6 )] 

c ' } -i 6 A c ) 

[assumption and predicate calculus] 

□ 



This simple proof is the advantage in defining the semantics of a loop using the 
strongest fixed-point. The next example shows its disadvantage. 

Example 7 (Non-termination and Hoare logic). 



p { true * I } q 

= p {vX • (I ; X) <\ true > l} q 
= p{T}q 

= ((p =* q') E T) 

= true 



[strongest fixed-point semantics] 
[strongest fixed-point] 
[definition of Hoare triple] 
[top element] 
□ 



This shows that a non-terminating loop is identified with miracle, and so imple- 
ments any specification. This drawback is the motivation for choosing weakest 
fixed-points as the semantics of recursion. We have already seen, however, that 
this also leads to problems. 

An example on the use of Hoare logic is presented below. 

Example 8 (Hoare logic proof for Swap ). Consider the little program that swaps 
two numbers, using a temporary register. 

Swap = t := a; a := b', b := t 

A simple specification for Swap names the initial values of a and b, and then 
requires that they be swapped. The correctness assertion is therefore given by 
the Hoare triple below. 

a = A A b = B {t. := a; a := b\ b := t} a = B A b = A 

This assertion can be discharged using the rules of Hoare logic. First, we apply 
the rule for sequence L6 to decompose the problem into two parts corresponding 
to the two sub-programs t := a\ a := b and b := t. This involves inventing 
an assertion for the state that exists between these two programs. Our choice is 
a = B A ( = 1 to reflect the fact that a now has the value of 6, and t holds the 
original value of a. 

a = A A 6 = B {t := a; a := b\ b := i} a = B A b = A 
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a = A A b = B {t. := cr, a := &} a = B A t = A (i)\ 

a = B A t = A {b ■— t} a = B A b = A (ii) ) 

Now we use L6 again; this time to decompose the first sub-program (i). 

/ a = A A b = B {t := a} b = B A t = A (iii) 

(i)<= [ A 

\b = B A t = A {a := 6} a = B A t = A (iv) 

Each of the remaining assertions (ii-iv) is discharged by an application of the 
rule for assignment, L4. □ 

This example shows how the correctness argument is structured by the ap- 
plication of each rule. Another way of using the rules is to assert only the post- 
condition; the precondition may then be calculated using the rules. We address 
this topic below. 




4.2 Weakest Precondition Calculus 

If we fix the program and the postcondition, then we can calculate an appropriate 
precondition to form a valid Hoare triple. As there will typically be many such 
preconditions, it is useful to find just one that can lead us to the others. From 
Hoare Logic Law L3, we have that if p {<?} r, then (jp A q) {Q} r. If we find 
the weakest precondition w that satisfies the Hoare triple w {Q} r, then this law 
states that every stronger precondition must also satisfy the assertion. 

To find w, we must manipulate the assertion to constrain the precondition 
to be at least as strong as some other condition. We parametrise p, Q, and r 
to make their alphabets explicit. The derivation expands the definition of the 
triple and of refinement, so that the precondition p(v) can be pushed into the 
antecedent of an implication. The rest of the derivation is simply tidying up. 

p(v) { Q{v, v') } r(v) [definition of Hoare triple] 

= {p{v) => r(V)) C Q(v,v') [definition of\A] 

= [ Q{v, v') => (p(v) =>■ r(v') ) ] [trading antecedents] 

= [p(u) => ( Q(v, v') => r(v') ) ] [restricting the quantification of v'[ 

= [p(u) => (V v' • Q(v,v') => r’ )] [De Morgan's quantifier rule] 

= [p(v) => -■ (3v' • Q(v,v') A -• r(V))] [change of variable] 

= [p(v) => -i ( 3 vq • Q{v, vo) A -i r(v o) ) ] [definition of sequence] 

= [p(v) => ( Q(v, v') ; -i r(v ) ) ] 

This says that if p holds, then it is impossible for Q to arrive in a state where r 
fails to hold. Every precondition must have this property; including, of course, 
-i (Q ; -i r) itself. We can summarise this derivation as follows. 

if w = -i ( Q ; ^ r ) then w { Q } r 
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The condition w is the weakest solution for the precondition for program Q to be 
guaranteed to achieve postcondition r. This useful result motivates and justifies 
the definition of weakest precondition. 

Q wpr = i (Q ; ■< r) 

The laws below state the standard weakest precondition semantics for the pro- 
gramming operators. 

LI ((x := e) wpr(x)) = r(e) assignment 

L2 ((P ; Q) wpr ) = ( P wp(Q wpr)) sequential composition 

L3 ((P <3 b > Q) wp r) = ((P wp r) <\ b t> (Q wp r)) conditional 

L4 ((P n Q) wp r) = (P wp r) A (Q wp r) nondeterministic choice 

Weakest precondition and Hoare logic, however, do not solve the pending issue 
of non-termination, to which we turn our attention now. 



5 Designs 

The problem pointed out in Section 2 can be explained as the failure of general 
alphabetised predicates P to satisfy the equation below. 

true ; P = true 

In particular, in Example 6 we presented a non-terminating loop which, when 
followed by an assignment, behaves like the assignment. Operationally, it is as 
though the non-terminating loop could be ignored. 

The solution is to consider a subset of the alphabetised predicates in which a 
particular observational variable, called okay , is used to record information about 
the start and termination of programs. The above equation holds for predicates 
P in this set. As an aside, we observe that false cannot possibly belong to this 
set, since false = false ; true. 

The predicates in this set are called designs. They can be split into precond- 
ition-postcondition pairs, and are in the same spirit as specification statements 
used in refinement calculi. As such, they are a basis for unifying languages and 
methods like B [1], VDM [7], Z, and refinement calculi [8,2,9]. 

In designs, okay records that the program has started, and okay' records that 
it has terminated. These are auxiliary variables, in the sense that they appear 
in a design’s alphabet, but they never appear in code or in preconditions and 
postconditions. 

In implementing a design, we are allowed to assume that the precondition holds, 
but we have to fulfill the postcondition. In addition, we can rely on the program 
being started, but we must ensure that the program terminates. If the precon- 
dition does not hold, or the program does not start, we are not committed to 
establish the postcondition nor even to make the program terminate. 
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A design with precondition P and postcondition Q , for predicates P and Q 
not containing okay or okay' , is written ( P b Q ). It is defined as follows. 

( P b Q ) = ( okay A P => okay' A Q ) 



If the program starts in a state satisfying P, then it will terminate, and on 
termination Q will be true. 

Abort and miracle are defined as designs in the following examples. Abort 
has precondition false and is never guaranteed to terminate. 

Example 9 (Abort). 



false b false 

= okay A false => okay 1 A false 
= false =t> okay' A false 
= true 

= false =t> okay' A true 
= okay A false => okay' A true 
= false b true 



[definition of design] 
[false zero for conjunction] 
[vacuous implication] 
[vacuous impliciation] 
[false zero for conjunction] 
[definition of design] 
□ 



Miracle has precondition true , and establishes the impossible: false. 

Example 10 (Miracle). 

true b false [definition of design] 

= okay A true => okay' A false [true unit for conjunction] 

= okay => false [contradiction] 

= -> okay □ 

A reassuring result about a design is the fact that refinement amounts to 
either weakening the precondition, or strengthening the postcondition in the 
presence of the precondition. This is established by the result below. 

Law 5 Refinement of Designs 

Pi b Qi C P 2 b Q 2 = [Pi A Q 2 =» Qi] A [Pr =► P 2 ] □ 



Proof. 



Pi b <5i C P 2 b q 2 
= [ ( P2 b Q 2 ) => ( Pi b Qi ) ] 

= [ ( okay A P 2 => okay' A Q 2 ) => ( okay A Pi => 

= [ ( P ‘2 => ofcaj/' A Q 2 ) => ( Pi => okay' A (Ji ) ] 



[definition ofQ] 
[definition of design, twice] 
okay' A Qi ) ] 

[case analysis on okay] 
[case analysis on okay'] 
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= [ ( ( Pi => Q2 ) => ( Pi => Qi ) ) A ( -> P2 => -> Pi ) ] [propositional calculus] 

= [ ( ( P 2 => Q 2 ) => ( -Pi => Qi ) ) A ( Pi => P 2 ) ] [predicate calculus] 

= [ Pi A Q2 => Qi ] A [ Pi => P 2 ] D 

The most important result, however, is that abort is a zero for sequence. This 

was, after all, the whole point for the introduction of designs. 

LI true ; (P b Q) = true left-zero 



Proof. 

true ; (P b Q) [property of sequential composition] 

= 3 okay 0 • true ; ( P b Q)[okay 0 / okay] [case analysis] 

= ( true ; (P b Q) [true / okay] ) V ( true ; (P b <5)[/alse/ofcat/] ) 

[property of design] 

= ( true ; (P b Q) [trwe/ofcay] ) V ( true ; true) [relational calculus] 

= ( true ; (P b (J) [trwe/ofcay] ) V true [propositional calculus] 

= true □ 



In this new setting, it is necessary to redefine assignment and skip, as those 
introduced previously are not designs. 

( x := e) = ( true hx'=eAy' = yA---Az' = z) 

I D = ( true b I ) 

Their existing laws hold, but it is necessary to prove them again, as their defi- 
nitions changed. 

L2 (v := e ; v := f(v)) = ( v := /(e)) 

L3 (v := e ; (P < b(v) !> Q )) = ((v := e ; P) <1 6(e) > (v := e ; Q )) 

Z-4 (I D ; (Pb Q)) = (Pb Q) 

As as an example, we present the proof of L2. 



Proof of L2. 

v := e ; v := /(v) [definition of assignment, twice] 

= ( true b»'=c);( true b«' = /(v) ) [case analysis on okayo] 

= ( ( true bt)'= e ) [true/ofcar/] ; ( true b»'= /(v) )[true/ofcay] ) V 

-1 okay ; true [definition of design] 

= ( ( okay =$■ v' = e) \ ( okay' A®' = /(d)))V^ ofca?/ [relational calculus] 
= okay => ( t/ = e ; ( okay 1 A v' = f(v) ) ) [assignment composition] 




A Tutorial Introduction to Designs in Unifying Theories of Programming 



55 



= okay => okay' A v' = /(e) [definition of design] 

= ( true b v' = /(e) ) [definition of assignment] 

= v:=f(e) □ 

If any of the program operators are applied to designs, then the result is also 
a design. This follows from the laws below, for choice, conditional, sequence, and 
recursion. The choice between two designs is guaranteed to terminate when they 
both are; since either of them may be chosen, then either postcondition may be 
established. 

T1 ( (P 1 b Qi) n (P 2 b Q 2 ) ) = ( P, A P 2 b Qi V Q 2 ) 

If the choice between two designs depends on a condition 6, then so do the 
precondition and the postcondition of the resulting design. 

72 ( (Pi b Qi) < b > (P 2 b Q 2 ) ) 

= ((Pi < b t> P 2 ) b ( <2i < 6 > Q 2 ) ) 

A sequence of designs (Pi b Qi) and (P 2 b Q 2 ) terminates when Pi holds, and 
<?i is guaranteed to establish P 2 . On termination, the sequence establishes the 
composition of the postconditions. 

T3 ( (Pr b ft) ; (P 2 b Q 2 ) ) 

= ((-.(-. Pi ; true) A (Qi wp P 2 )) b {Qi ; Q 2 ) ) 

Preconditions can be relations, and this fact complicates the statement of Law 
73; if the Pi is a condition instead, then the law is simplified as follows. 

T3 ( (pi b Qi) ; (P 2 b Q 2 ) ) = (pi A (Qi wp P 2 )) b (Qi ; Q 2 ) ) 

A recursively defined design has as its body a function on designs; as such, it 
can be seen as a function on precondition-postcondition pairs (A, Y). Moreover, 
since the result of the function is itself a design, it can be written in terms of a 
pair of functions F and G, one for the precondition and one for the postcondition. 

As the recursive design is executed, the precondition F is required to hold 
over and over again. The strongest recursive precondition so obtained has to 
be satisfied, if we are to guarantee that the recursion terminates. Similarly, the 
postcondition is established over and over again, in the context of the precon- 
dition. The weakest result that can possibly be obtained is that which can be 
guaranteed by the recursion. 

74 (pA, Y • {F(X, Y) b G(X, Y) ) ) = (P(Q) b Q) 

where P{Y) = (i/A • P( A, Y)) and Q = (pY • P{Y) => G(P(T), 7)) 

Further intuition comes from the realisation that we want the least refined fixed- 
point of the pair of functions. That comes from taking the strongest precondition, 
since the precondition of every refinement must be weaker, and the weakest 
postcondition, since the postcondition of every refinement must be stronger. 
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Like the set of general alphabetised predicates, designs form a complete lat- 
tice. We have already presented the top and the bottom (miracle and abort). 

T D = ( true b false ) = -i okay 
_I_ D = ( false b true ) = true 

The least upper bound and the greatest lower bound are established in the 
following theorem. 

Theorem 1. Meets and joins 

n 8 (P*b Qi) = (A i p i )\-(\/ i Qi) 

I— 1»( Pi I - Qi) = ( V i p i) ^ ( Ai Pi =*■ ft ) 

As with the binary choice, the choice n.(P» b Qi) terminates when all the 
designs do, and it establishes one of the possible postconditions. The least upper 
bound models a form of choice that is conditioned by termination: only the 
terminating designs can be chosen. The choice terminates if any of the designs 
does, and the postcondition established is that of any of the terminating designs. 

6 Healthiness Conditions 

Another way of characterising the set of designs is by imposing healthiness con- 
ditions on the alphabetised predicates. Hoare & He identify four healthiness 
conditions that they consider of interest: HI to H4. We discuss each of them. 

6.1 HI: Unpredictability 

A relation R is HI healthy if and only if R = ( okay => R). This means that 
observations cannot be made before the program has started. A consequence is 
that R satisfies the left-zero and unit laws below. 

true ; R = true and I D ; R = R 

We now present a proof of these results. 

Designs with left-units and left-zeros are HI 

R 

= I D \ R 

= ( true b I D ) ; R 
= ( okay => okay' A I ) ; R 
= ( -i okay ; R) V ( J ; R) 

= ( -i okay ; true ; R) V ( J ; R) 

= -i okay V ( I ; R ) 

= -i okay V R 
= okay => R 



[assumption (I D is left-unit)] 
[I D definition] 
[design definition] 
[relational calculus] 
[relational calculus] 
[assumption (true is left-zero)] 
[assumption (I is left-unit)] 
[relational calculus] 
□ 
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HI designs have a left-zero. 

true ; R 

= true ; ( okay => R ) 

= ( true ; -> okay ) V ( true ; R ) 

= true V ( true ; R ) 

= true 

HI designs have a left-unit. 

Id ; R 

= ( true h I D ) ; R 
= ( okay => okay' A I ) ; R 
= ( -i okay ; R ) V ( okay A R ) 

= ( -i okay ; true ; i? ) V ( okay A R) 
= ( -i okay ; true ) V ( okay A R) 

= -i okay V ( ofcay A i? ) 

= ofcay => i? 

= R 



[assumption (R is HI)] 
[relational calculus] 
[relational calculus] 
[relational calculus] 
□ 



[definition of I D ] 
[definition of design] 
[relational calculus] 
[relational calculus] 
[true is left-zero] 
[relational calculus] 
[relational calculus] 
[R is HI] 
□ 



This means that we could use the left-zero and unit laws to characterise HI . 



6.2 H2: Possible Termination 

The second healthiness condition is [ R. [false / okay'] => R.[true/ okay']]. This 
means that if R is satisfied when okay' is false, it is also satisfied then okay' 
is true. In other words, R cannot require nontermination, so that it is always 
possible to terminate. 

The designs are exactly those relations that are HI and H2 healthy. First we 
present a proof that relations that are HI and H2 healthy are designs. 



HI and H2 healthy relations are designs. Let R^ = R[false / okay'] and R.' = 
R[true / okay']. 



R 

= okay => R 

= okay => ( -i okay' A R* ) V ( okay' A R * ) 

= okay => ( -i okay' A Rf A R l ) V ( okay' A R l ) 
= okay =>(((-> okay' A Rf ) V okay' ) A R l ) 

= okay => ( ( Rf V okay' ) A R l ) 

= okay =4> ( Rf A R l ) V ( okay' A R* ) 



[assumption (R is HI)] 
[propositional calculus] 
[assumption (R is H2)[ 
[propositional calculus] 
[propositional calculus] 
[propositional calculus] 
[assumption (R is H2)[ 
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= okay => Rf V ( okay' A R l ) 
= okay A -> Rf =>■ okay' A P* 
= Rf h P f 



[propositional calculus] 
[design definition] 
□ 



It is very simple to prove that designs are HI healthy; we present the proof 
that designs are H2 healthy. 



Designs are H2. 

{P b Q) [false / okay'] 

= ( okay A P => false ) 
=> ( okay A P => Q ) 

= ( P b Q ) [true / okay'] 



[definition of design] 
[propositional calculus] 
[definition of design] 
□ 



While HI characterises the role of okay, H2 characterises okay' . Therefore, it 
should not be a surprise that, together, they identify the designs. 



6.3 H3: Dischargeable Assumptions 

The healthiness condition H3 is specified as an algebraic law: R = R ; I D . A 
design satisfies H3 exactly when its precondition is a condition. This is a very 
desirable property, since restrictions imposed on dashed variables in a precondi- 
tion can never be discharged by previous or successive components. For example, 
x' = 2 b true is a design that can either terminate and give an arbitrary value 
to x , or it can give the value 2 to x, in which case it is not required to terminate. 
This is a rather bizarre behaviour. 

A design is H3 iff its assumption is a condition. 

( ( P b Q) = {{P \- Q) ; I „)) [definition of design-skip] 

= ((Ph<5) = ((PI _ (5);( true h I D ) ) ) [sequence of designs] 

= ( ( P b Q ) = ( “t ( P ; true ) A -> ( Q ; -> true ) h Q ; I D ) ) [skip unit] 
= ((Ph <3) = ( _, (^P; true ) b Q ) ) [design equality] 

= ( -i P = -i P ; true ) [propositional calculus] 

= ( p = p ; true ) □ 

The final line of this proof states that P = 3v' • P, where t/ is the output 
alphabet of P. Thus, none of the after- variables’ values are relevant: P is a 
condition only on the before-variables. 



6.4 H4: Feasibility 

The final healthiness condition is also algebraic: P ; true = true. Using the 
definition of sequence, we can establish that this is equivalent to 3 v' • R, where 
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v' is the output alphabet of if. In words, this means that for every initial value 
of the observational variables on the input alphabet, there exist final values for 
the variables of the output alphabet: more concisely, establishing a final state is 
feasible. The design T D is not H4 healthy, since miracles are not feasible. 



7 Theories of Program Correctness Revisited 

In this section, we reconsider our theories of program correctness in the light of 
the theory of designs. We start with assertional reasoning, which we postponed 
until we had an adequate treatment of termination. We review Hoare logic and 
weakest preconditions, before introducing the refinement calculus. 



7.1 Assertional Reasoning 

A well-established reasoning technique for correctness is that of assertional rea- 
soning. It uses assumptions and assertions to annotate programs: write condi- 
tions that must, or are expected to, hold in several points of the program. If 
the conditions do hold, assumptions and assertions do not affect the behaviour 
of the program; they are comments. If the condition of an assumption does not 
hold, the program becomes miraculous; if the condition of an assertion does not 
hold, the program aborts. 

c T = I D <1 c > T d 

C_L = I D <1 C> 1„ 

For simplicity, we ignore the alphabets in these definitions. 

The following law establishes that a sequence of assertions can be joined. 

Law 6 (Composition of Assertions) 

b± ; c± = (b A c)j_ □ 



[assumption] 

[assertion] 



Proof. 



b± ; c_l [definition of assertion] 

= (I D <J b > _I_ D ) ; c_l [composition left-distribution over conditional] 



= (( I D ; c_l) < b > (_I_ D ; cjJ) 
= (c_l < b > (_L d ; c_l)) 

= (cj_ <J b > _I_ D ) 

= ( ( -L d <1 c O T D ) <1 b O T D ) 
= (X D <] 6 A c > T D ) 

= (b A c)_l 



[left-unit for sequence (L4)[ 
/T D left-zero for sequence (Ll)[ 
[definition of assertion] 
[conditional associativity (L3)[ 
[definition of assertion] 
□ 



Reasoning with assertions often involves distributing them through a program. 
For example, we can move an assertion over an assignment. 
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Law 7 (Assertions and Assignments) 

(c(e)j l ;x := e) = ( x := e; c(a;)j_) 



□ 



Proof. 

c(e)_L ; x := e 

= (I D <] c(e) > _L d ) ; x e 
= I D ; x := e <1 c(e) > _L D ; a; := e 
= x := e <\ c(e) [> J_ D 
= x := e •, I D < I c(e) > a; := e ; J_ D 
= x := e ; (J D <] c(a;) > _L D ) 

= x := e; c(x)± 



[definition of assertion] 
[sequence L2] 
[x := e is a design (HI)] 
[x := e is H3 and H4] 
[design assignment Law L3] 
[definition of assertion] 
□ 



Finally, we present below a law for distributing assertions through a conditional. 



Law 8 (Assertions and Conditionals) 

c± ; (P <1 b [> Q) = ((b A c)± ; P <J b > (-> b A c)_l ; Q) □ 

We leave the proof of this law as as exercise. 



7.2 Hoare Logic 

In Section 4, we define the Hoare triple for relations as follows. 
p{Q}r = (p => r') E Q 



The next two examples show that this is not appropriate for designs. First, we 
consider which specifications are satisfied by an aborting program. 

Example 11 (Abort). 



P {-Ld} d r 

= p { false b true } r 
= p { okay A false => okay' A true } r 
= p {true} D r 
= [ true => (p =>■ r') } 

= [p => r' ] 



[definition of _I_ D / 
[definition of design] 
[propositional calculus] 
[definition of Hoare triple] 
[propositional calculus] 
□ 



This is simply wrong, since it establishes the validity of 
true { J_ D } true 



Here the requirement is for the program to terminate in every state — which 
abort clearly does fails to do. Next, we consider which specifications are satisfied 
by a miraculous program. 
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Example 12 (Miracle). 

P { T °} d r 

= p { true b false } r 
= p { okay A true => okay' A false } r 
= p { -i okay } r 
= [ * okay =>■ (p => r') } 

= [ -i true => (p => r') ] A [ -> false => (p => r') ] 
= [p=>r'} 

= p{± 0 } D r 



[definition of T D ] 
[definition of design] 
[propositional calculus] 
[definition of Hoare triple] 
[case analysis] 
[propositional calculus] 
[from Example 11] 
□ 



Again, this is simply wrong, since it is the same result as before — and a miracle 
is surely different from an aborting program! So, we conclude that we need to 
adjust the definition of Hoare triple for designs. For any design Q , we define the 
Hoare triple as follows. 



p{Q } D r = (p h r') C Q 



If we replay our two examples, we get the expected results. First, what specifi- 
cations are satisfied by an aborting program? 



Example 13 (Abortive implementation). 
P {-Ld} d r 

= p { false b true } r 
= [ ( false b true ) => ( p b r ' ) ] 

= [ ( p => false ) A ( p A true => r ) ] 
= [ -■ P A ( p => r' ) ) 

= b p } 



[definition of E 0 ] 
[definition of Hoare triple] 
[definition of design, twice] 
[propositional calculus] 
[propositional calculus] 
□ 



The answer is that the precondition must be a contradiction. Next, what speci- 
fications are satisfied by a miraculous program? 



Example If (Miraculous implementation) . 
P { T °} D r 

= p { true b false } r 
= [ ( true b false ) => ( p b r ' ) ] 

= [ ( p =$■ true ) A ( p A false => r' ) ] 

= [ true } 



[definition of T 0 ] 
[definition of Hoare triple] 
[definition of design, twice] 
[propositional calculus] 
[predicate calculus] 



= true 



□ 
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The answer is that a miracle satisfies every specification. 

We now prove that Hoare logic rule LI holds for the new definition. 

(p {Q} D r) A (p { Q} d s) [definition of design Hoare triple] 

= ((p b r') C Q) A ((p b s') O Q) [separation of requirements] 

= (p b r') A (p b s') C Q [definition of designs] 

= ( okay A p => okay' A r') A ( okay A p => okay' A s') C Q 

[propositional calculus] 

= ( okay A p => ofcap' A okay' A r' A s') C Q [definition of design] 

= (p b r' A s') C <5 [definition of design Hoare triple] 

= p{Q} D r A s n 

Other rules may be proved in a similar way. 



7.3 Weakest Precondition 

Once more, we can use our definition of a Hoare triple to derive an expression 
for the weakest precondition of H3 healthy designs. 



p{P b Q} d r 
(p I" r') E (P b Q) 

[ (p => P) A (p A <2 => r') ] 
[p => P A (Q => r')] 
[V«'«pAPA(Q=>r')] 
[ p =>■ V t;' • P A ( <2 => r') } 
P A (V w' • <2 => r') ] 
P A ^ (3 v' • -i (Q 
P A -i (3 v' • Q A 



LP 

[p 

[p 

\P 



[definition of Hoare triple] 
[refinement of designs] 
[propositional calculus] 
[predicate calculus] 
[since v' not free in a] 
[assumption (P b Q is H3): v' not free in P] 
[De Morgan s quantifier law] 
> r')) ] [propositional calculus] 

r')] [definition of sequential composition] 

□ 



P a — > ( <2 ; t ) ] 

This motivates our new definition for the weakest precondition for a design. 

( P b Q ) wp D r — ( P A ( <2 wpr)) 

This new definition uses the wp operator introduced before. 



7.4 Specification Statements 

Our final theory of program correctness is Morgan’s refinement calculus [8]. 
There, a specification statement is a kind of design. The syntax is as follows. 

frame : [precondition, postcondition ] 
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The frame describes the variables that are allowed to change, and the precondi- 
tion and postcondition are the same as those in a design. 

For example, the specification statement x : [y ^ 0,x' = x div y] is repre- 
sented by the design y ^ 0 b ( x' = x div y )+ y , providing that the only program 
variables are x and y. 

The refinement law for assignment introduction is as shown below. 



Law 9 Assignment Introduction in the Refinement Calculus 
providing that [p => Q[e/w']] 

w,x : [p, Q] C w := e □ 



Proof, 
w := e 

= true b ( w' = e )+{ x , y } 

□ p \- (w' = e )+{ x ,s/} 

= P I" ( Q[e/w') A w' = e )+{ x , y } 
= p b ( Q A w' = e )+{ x ,y} 

= p\-(Q/\w' = e/\x' = x )+ y 
3 P b Q+y 
= w,x: [ p,Q } 



[definition of assignment] 
[weaken precondition] 
[assumption] 
[Leibniz] 
[alphabet extension] 
[strengthen postcondition] 
[definition of specification statement] 

□ 



Another important law allows the calculation of conditionals. 



Law 10 Conditional Introduction in the Refinement Calculus 



providing that [p => V * • 9i ] 



if 9\ - 


-A W 


□ 

to 

1 


-A W 



w :[p,Q] C { 



D g n - 


-A W 


fi 





[ffi A p,Q] 
[92 A p,Q ] 

[_ 9 n Cp,Q] 



□ 



This law uses a generalised form of conditional, present in Dijkstra’s language 
of guarded commands [4] and in Morgan’s calculus. The conditions are called 
guards, and the choice of branch to execute is nondeterministic among those 
whose guards are true. The definition of this guarded conditional is not difficult, 
but here we consider just the conditional operator we have presented before. 
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Proof of binary case : w : [p, Q] C (w \ [g A p, Q] <\ g \> w : [^ g A p, Q\). 

In order to prove this refinement, we can resort to Law 1 and proceed by 
case analysis. In this case, we need to prove w : [p,Q] Cj Aw : [g A p, Q] and 
w : [p,Q] Cn jAf : g A p, Q}. Below, we prove the first case; the second 

case is similar. 



g A w : [g A p, Q ] [definition of specification statement] 

= U A (j A p h Q+ x ) [definition of alphabet extension] 

= g A (g A p \- Q A x' = x) [definition of design] 

= g A ( okay A g A p => okay' A Q A x' = x ) [propositional calculus] 

= g A ( okay A p =>■ okay 1 A Q A x' = x ) [propositional calculus] 

=> ( okay Ap4- okay' A Q A x' = x ) [definition of design] 

= p h Q +x [definition of specification statement] 

= w:[p,Q } □ 



Next, we present an example of the application of the refinement calculus. The 
problem is to calculate the maximum and minimum of two numbers. 

Example 15 (Finding the maximum and the minimum) . The problem has a sim- 
ple specification: x, y : [ true, x' = max(x, y) A y' = min(x , y) ]. Our first step is 
to use Law 10 to introduce a conditional statement that checks the order of the 
two variables. 



x, y : [ true, x' = max{x, y) A y' = min{x, y) ] 

( x, y : [x < y,x' = max(x, y) A y' = min{x, y) ] (i)\ 

<i x < y > 

x, y : [ x > y, x' = max{x, y) A y' = min(x, y) ] (ii) J 

The ‘then’ case is easily implemented using a multiple assignment, a generalised 
assignment that updates a list of variables in parallel. Its semantics and proper- 
ties are similar to those of the single assignment; in particular, Law 9 holds. 

(i) C x,y := y,x 

providing that 

[ x < y => ( x' = max(x, y) A y' = min{x, y))[y,x/x',y']] 

which follows from substitution and properties of the max and min functions. 
The ‘else’ case is even simpler, since the variables are already in the right order. 

(ii) C skip 

providing that 

[ x >?/=>( x' = max(x, y) A y' = min(x, y) )[x, y/x', y'\ ] 
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The development may be summarised as the following refinement. 

x, y : [ true , x' = max(x, y) A y' = min(x, y) } 

C 

if x < y then x, y := y,x else skip fi 



if x < y then x, y := y,x fi □ 

There are many other laws in the refinement calculus; we omit them for the sake 
of conciseness. 

8 Conclusions 

Through a series of examples, we have presented the alphabetised relational cal- 
culus and its sub-theory of designs. In this framework, we have presented the 
formalisation of four different techniques for reasoning about program correct- 
ness. The assertional technique, the Hoare logic, and the weakest preconditions 
are presented in [6] ; our original contribution is a recasting of Hoare logic and 
weakest preconditions in the theory of designs, and an outline of the formalisa- 
tion of Morgan’s calculus. 

We hope to have given a didactic and accessible account of this basic founda- 
tion of the unifying theories of programming. We have left out, however, most of 
the more elaborate programming constructs contemplated in [6]. These include 
theories for concurrency, communication, and functional, logic, and higher-order 
programming. We also have not discussed their account of algebraic and opera- 
tional semantics, nor the correctness of compilers. 

In our recent work, we have used the theory of communication and concur- 
rency to provide a semantics for Circus [13], an integration of Z and CSP [11] 
aimed at supporting the development of reactive concurrent systems. We have 
used the semantics to justify a refinement strategy for Circus based on calcula- 
tional laws in the style of Morgan [3] . 

In [10], UTP is also used to give a semantics to another integration of Z and 
CSP, which also includes object-oriented features. In [12], UTP is extended with 
constructs to capture real-time properties as a first step towards a semantic 
model for a timed version of Circus. In [5], a theory of general correctness is 
characterised as an alternative to designs; instead of HI and H2 , a different 
healthiness condition is adopted to restrict general relations. 

Currently, we are collaborating with colleagues to extend UTP to capture 
mobility, synchronicity, and object orientation. We hope to contribute to the 
development of a theory that can support all the major concepts available in 
modern programming languages. 
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Abstract. Finding tractable methods for program reasoning remains a 
major research challenge. Here we address this challenge using an inte- 
grated approach to tackle a niche program reasoning application. The 
application is proving exception freedom, i.e. proving that a program is 
free from run-time exceptions. Exception freedom proofs are a significant 
task in the development of high integrity software, such as safety and se- 
curity critical applications. The SPARK approach for the development 
of high integrity software provides a significant degree of automation in 
proving exception freedom. However, when the automation fails, user in- 
teraction is required. We build upon the SPARK approach to increase the 
amount of automation available. Our approach involves the integration 
of two static analysis techniques. We extend the proof planning paradigm 
with program analysis. 



1 Introduction 

Program reasoning has been an active area of research since the early days of 
computer science, as demonstrated by a program proof by Alan Turing [36]. 
However, as highlighted in [27] the search for “tractable methods” has remained 
a key research challenge. Here we address this challenge by considering the in- 
tegration of two distinct static analysis techniques. The first is proof planning 
[4], a theorem proving technique developed by the automated deduction com- 
munity. The second is program analysis , a general technique for automatically 
discovering interesting properties from a program’s source code. 

For our program reasoning we have focused on the SPARK programming 
language [1]. SPARK is designed for the development of high integrity software, 
as seen in safety and security critical applications. Our primary interest is in the 
development of automatic methods for proving exception freedom in SPARK 
programs, i.e. proving that a program is free from run-time exceptions. Such 
program reasoning represents an important task in the development of high 
integrity software. For instance, the loss of Ariane 5 was a result of an inte- 
ger overflow run-time error [15], while buffer overflows are the most common 
form of security vulnerability [12]. The SPARK toolset supports proof of ex- 
ception freedom using formal verification. This reduces the task of guaranteeing 
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exception freedom to proving a number of theorems called verification condi- 
tions (VCs). Industrial strength evidence [9] shows that the SPARK toolset can 
typically prove around 90% of such VCs automactically. Our work targets the 
remaining 10%. These typically account for hundreds of VCs, each requiring user 
interaction to complete the proof. 

Background material on SPARK and the nature of the verification problem 
being addressed is presented in §2. In §3 we compare proof using the SPARK 
toolset to proof following our approach. The details of our approach are presented 
in §4, §5, §6 and §7. In §8 related work is discussed while in §9 progress and future 
work are outlined. Our conclusions are presented in §10. 



2 Background to the Problem 

2.1 The SPARK Approach 

The SPARK programming language is defined as a subset of Ada [26]. SPARK 
excludes many Ada constructs, such as pointers, dynamic memory allocation 
and recursion to make static analysis of SPARK feasible. SPARK includes an 
annotation language that supports flow analysis and formal proof. In the case 
of formal proof the annotations capture the program specification, asserting 
properties that must be true at particular program points. The annotations are 
supplied within regular Ada comments, allowing a SPARK compliant program 
to be compiled using any Ada compiler. 

Compliance to the SPARK language is enforced by a static analyser called the 
EXAMINER. In addition, the EXAMINER performs data flow and information flow 
analysis [3]. The EXAMINER supports formal verification by building directly 
upon the Floyd/Hoare style of reasoning. VCs can be generated for proofs of 
both partial correctness and exception freedom. Two additional tools called the 
SPADE SIMPLIFIER and SPADE PROOF checker are used to prove these VCs. 
The SIMPLIFIER is a special purpose theorem prover designed to automatically 
discharge relatively simple VCs while the PROOF checker is an interactive proof 
development environment. 



2.2 SPARK Exception Freedom 

By its definition, SPARK eliminates many of the run-time exceptions that can be 
raised within Ada. However, index, range, division and overflow checks can still 
raise exceptions in SPARK code. The EXAMINER generates run-time check (RTC) 
VCs to statically guard against such exceptions. The RTC VCs are equivalent 
to the Ada run-time checks, consequently proving every RTC VC guarantees 
exception freedom. To generate VCs every loop must be annotated with an 
invariant. To support proof of exception freedom for sparsely annotated SPARK 
code, the EXAMINER automatically inserts invariants as will be described in §5.2. 

To illustrate the problems associated with proving RTC VCs consider the 
SPARK code given in Figure 1. Note that this is used as a running example 




An Integration of Program Analysis and Automated Theorem Proving 



69 



package FilterPackage is 
subtype AR_T is Integer 
range 0 . . 9 ; 

type A_T is array (AR_T) 
of Integer; 

procedure Filter (A: in A_T ; 

R: out Integer) ; 
— #derives R from A; 
end FilterPackage; 



package body FilterPackage is 
procedure Filter (A: in A_T; 

R: out Integer) 
is 

begin 
R: =0 ; 

for I in AR_T loop 

if A(I)>=0 and A(I)<=100 then 
R:=R+A(I) ; 
end if ; 
end loop; 
end Filter; 
end FilterPackage; 



Note that while — # represents an Ada comment it also denotes a SPARK 
annotation. Here the annotation is describing the flow information that R is 
derived from array A in subprogram Filter. This specification is checked au- 
tomatically by the examiner during its information flow analysis. 



Fig. 1. Filter and sum values in an array 



throughout the paper. Consider the assignment statement in the then-branch, 
i.e. R : =R+A (I) , whose corresponding RTC VC is given in Figure 2. There are two 
aspects to proving that this assignment can not raise an exception. Firstly, we 
must show that the value of I can never exceed the range of array A, i.e. Cl and 
C2. Secondly, we must show that the value of the expression R+A(I) lies within 
the legal bounds of R, i.e. C3 and C4. While proving Cl and C2 is trivial (match 
with H2 and H3 respectively), C3 and C4 are improvable. This problem arises as 
there is insufficient proof context. Note that the RTC VCs involve proving that 
variables lie inside legal bounds. This is the case for all RTC VCs, allowing us 
to target our proof techniques and program analysis accordingly. 

3 Comparing Proof in SPARK with Our Approach 

3.1 Proof via the SPARK Toolset 

Completing a program proof in the SPARK toolset typically requires several 
steps of user interaction. The general proof process undertaken is summarised 
below. 

1. Incomplete proof: For each VC yet to be proved the user must determine 
the reason for the failure, implement a suitable patch, and then repeat this 
proof process. Three reasons for failure are considered, 
a) Insufficient proof context: The VC is improvable as the proof context 
is not sufficiently strong. The user must introduce the required proof 
context by strengthening the program specification. 
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HI: for_all (i 1: integer, ( ( i 1 >= ar_t first) and 

(i 1 <= ar_t last)) -> ((element (a, [i 1] ) >= 

integer first) and (element (a, [i 1] ) <= integer last))) . 

H2: loop 1 i >= ar_t first . 

H3: loop 1 i <= ar_t last . 

H4: element (a, [loop 1 i] ) >= 0 . 

H5: element (a, [loop 1 i] ) <= 100 . 

-> 

Cl: loop 1 i >= ar_t first . 

C2: loop 1 i <= ar_t last . 

C3: r + element(a, [loop 1 i] ) >= integer first . 

C4: r + element(a, [loop 1 i] ) <= integer last . 

The examiner generates eight VCs for the running example of Figure 1. Three 
of these are RTC VCs, while the rest are proving properties asserted by the 
examiner. The RTC VC above corresponds to proving that the assignment 
in the then-branch can never raise an exception. Here HI, H2 and H3 are a 
result of the invariant automatically inserted by the examiner. Note that 
element(a, [i]) denotes accessing array a at index i. 



Fig. 2. A run-time check verification condition (RTC VC) 



b) Discovered a bug: The VC can be proved to be false. This indicates 
the presence of a bug in the source code or specification. The VC will 
typically give a strong clue as to the nature of the bug. The user must 
modify the code or specification to eliminate the bug. 

c) Beyond the simplifier: The VC is provable however its proof is be- 
yond the scope of the simplifier. The user must prove the VC via an 
interactive session with the PROOF CHECKER. 

2. Complete proof: Every VC is discharged by the SIMPLIFIER and any user 
guided proofs created in the PROOF CHECKER. 

This process is rarely intellectually demanding. However, typically many hun- 
dreds of proof failures need to be patched per application. Further, all interac- 
tive proofs will be tuned to a particular version of a program. As the program is 
changed these proofs may break and require refinement. Thus this task presents 
a significant bottle-neck to the practical completion of exception freedom proofs. 



3.2 Proof via Our Approach 

Our approach reduces the amount of user interaction required to complete a 
proof. We extend the existing SPARK toolset with a new tool called NUSPADE 1 . 
NUSPADE is a proof planner that also incorporates program analysis. By using 
NUSPADE aspects of the proof process outlined above can be automated. 

1 The name NUSPADE emphasises that we are building upon SPADE. 
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1. Incomplete proof: Each VC yet to be proved is automatically tackled by 
NUSPADE. If NUSPADE successfully finds a proof plan then this is exported as 
a customised tactic for execution inside the PROOF CHECKER. If NUSPADE 
fails to find a proof plan three situations are possible. 

a) Insufficient proof context: If NUSPADE is able to identify missing 
proof context then it can exploit the services of a program analysis oracle 
to enhance the program specification accordingly. 

b) Discovered a bug: If NUSPADE reduces a VC to false then it must 
indicate a bug. Although not considered further in this paper, there is 
scope for configuring NUSPADE to actively detect common programing 
errors. This will involve targeting the forms of VCs that these errors 
tend to produce with suitable disproving methods. 

c) Require user interaction: If the above cases do not apply, NUSPADE 
is unable to progress. The user must pursue the interactive proof process 
outlined above in §3.1. 

2. Complete proof: Every VC is discharged by the SIMPLIFIER, any tac- 
tics created by NUSPADE and any user guided proofs created in the PROOF 
CHECKER. 

4 Proof Planning 

Proof planning is an artificial intelligence technique for guiding tactic based the- 
orem provers. It has been extensively investigated within the context of proof 
by mathematical induction [6]. A proof plan represents the pattern associated 
with a family of proofs and is used to guide the search for the proof of a given 
conjecture within the family. A successful search instantiates the proof plan for 
the given conjecture. From the instantiated proof plan a tactic can be mechani- 
cally extracted and automatically checked using an appropriate theorem prover. 
Adopting this approach passes the burden of soundness to the theorem prover. 
Free from the constraints of demonstrating soundness, greater flexibility is pos- 
sible when planning a proof. 

A proof plan corresponds to a set of methods. Each method expresses pre- 
conditions for the applicability of a particular tactic. The methods are typically 
less expensive to execute and more constrained than their corresponding tactics. 
Another significant component of proof planning is the proof critics mechanism 
[19,21]. Proof critics are associated with the partial success of proof methods 
and provide a mechanism for patching failed proofs. 



4.1 Exception Freedom Methods 

Our exception freedom proof plan contains four methods as outlined below. Note 
that these appear in the order used within the proof planner, i.e. the simpler 
more immediate methods are tried first. Further, note that the details of these 
methods will be described in more detail in §7.2. 
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Preconditions for transitivity method: 

1. There exists a goal of the form: 
E Rel C. 

2. For all variables V that occur within 
E there exists a hypothesis of the 
form: Vi Rel Ei. 



Preconditions for transitivity critic: 

1. Precondition 1 of the transitivity 
method holds, i.e. there exists a goal 
of the form: E Rel C . 

2. Precondition 2 of the transitivity 
method fails, i.e. there exists a vari- 
able V. that occurs within E such 
that there does not exist a hypothesis 
of the form: V Rel Ei. 



Note that E and C range over expressions and constants respectively, while 
Rel denotes a transitive relation. 



Fig. 3. Preconditions for the transitivity method and critic 



1. elementary: Applicable to goals that are automatically discharged by the 
PROOF CHECKER, modulo some minor simplifications. 

2. fertilise: Applicable where part of a goal matches a hypothesis, producing a 
simplified goal. 

3. decomposition: Applicable to a transitive relation within a goal, decomposing 
its term structure. 

4. transitivity: Applicable to a goal involving a transitive relation, introducing 
a transitive step into the proof. 



4.2 Exception Freedom Critics 

In our exception freedom proof plan a proof critic is associated with the transitiv- 
ity method. The transitivity critic detects insufficient proof context. It describes 
the missing proof context using hypotheses schemata. The preconditions for the 
transitivity method and critic are presented in Figure 3. Note that the precondi- 
tions of the transitivity critic are expressed in terms of the partial success of the 
preconditions of the transitivity method. 



4.3 Failed Proof Plan 

To illustrate the behaviour of our exception freedom proof plan we return to our 
running example of Figure 1 and its corresponding RTC VC for the then-branch 
shown in Figure 2. We focus on the goal of proving C4, 

r + element(a, i) < integer .last , 

noting that the proof context includes the hypothesis H5 



element{a , i) < 100 . 
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All methods completely fail except the transitivity method which is partially 
successful. In the following A, B, X and Y range over expressions. The goal 
satisfies the first precondition of the transitivity method as there exists a goal of 
the form E Rel C. However, the second precondition fails, as variable r exists 
within r + element(a,i ) yet there is no hypothesis matching r < B. Note that 
element(a, i) does not cause the second precondition to fail as there does exist a 
hypothesis of the form element(a , i) < Y . The proof plan for the lower bound of 
r -\- element {a, i) similarly fails as there does not exist a hypothesis that matches 
r > A and there does exist a hypothesis that matches element(a, i ) > X. Each 
of these failure patterns trigger the transitivity critic, suggesting the need for 
additional hypotheses corresponding to the schema 

(r > A) A(r < B) . 

This schema suggests that additional information on the bounds of r needs to 
be introduced through the discovery of a stronger loop invariant. Below in §5 we 
describe how this discovery is automated through program analysis. 



5 Program Analysis 

Program analysis involves automatically calculating interesting properties about 
source code. Different program analysis techniques have been presented, includ- 
ing flow analysis [3], performance analysis [14] and discovering constraints on 
variables [11]. 

Although VCs are generated by combining source code with its specification 
they typically reveal only a subset of this information. Thus, it is reasonable to 
return to the source code and its corresponding specification. For example, in 
[28] invariant discovery is tackled through top-down and bottom-up approaches, 
exploiting the specification and source code respectively. Top-down approaches 
are more applicable in the presence of a strong specification. As exception free- 
dom proofs are typically performed on minimally annotated code the top-down 
approach is less effective. However, we believe that top-down approaches have 
a significant role to play in assisting partial correctness proofs [23]. Bottom-up 
approaches are more applicable where low level implementation detail is desired. 
This is especially suitable for exception freedom proofs, which involve reason- 
ing about the low level details of an algorithm. Thus we focus on extracting 
properties from the source code using program analysis. 

5.1 Program Analysis Oracle 

Program analysis for program verification typically involves the use of heuristic 
based techniques, as seen in [28,18]. These techniques can be quite unstructured, 
with different techniques interacting in various ways and often targeting a partic- 
ular area of a program. In particular, these techniques often produce candidate 
properties that require nontrivial reasoning in order to prove their correctness. 
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Thus it is not practical to capture such imprecise techniques in a formal man- 
ner. Our strategy is to view program analysis as an oracle. The system produces 
candidate properties for use during proof planning. The soundness of the en- 
tire approach is ensured by the execution of the tactics generated by the proof 
planner. 

We capture distinct program analysis heuristics as program analysis meth- 
ods. Our program analysis begins by first translating the input source code into 
a flowchart. The program analysis methods are then called in series to anno- 
tate the flowchart with abstract values , i.e. approximate descriptions of program 
variables. Each method employs a suitable representation to describe these ab- 
stract values. Once all of the methods have completed, a collection of program 
properties are extracted from the annotated flowchart. These properties may be 
accessed during proof planning to assist in the verification effort. 

5.2 Program Analysis Performed by the Examiner 

As mentioned in §2.2, the EXAMINER automatically inserts invariants to enable 
proof of exception freedom in minimally annotated SPARK. In addition to this 
the examiner also inserts preconditions to enrich the program specification. 
This behaviour captures the spirit of our program analysis, i.e. exploiting infor- 
mation in the source code to automatically discover useful properties. 

The EXAMINER adds a precondition that every imported subprogram param- 
eter is within its type. Further, the EXAMINER adds a default invariant of true for 
each loop. This is strengthened by asserting that for loop iterators are within 
their type. Further, any precondition is copied into the invariant adjusting all 
variables to refer to their initial, rather than current, value. 

5.3 Program Analysis Methods 

Based on industrial strength examples and focusing on exception freedom proofs 
a small collection of program analysis methods have been established. These are 
presented in the following sections. For brevity the examples presented focus on 
regular program variables. However, they can be naturally extended to deal with 
arrays and records, the two main SPARK structures. 

5.4 Method: Type 

SPARK adopts the strong Ada type system, imposing some additional con- 
straints to ease static analysis. As type information directly reveals a variables 
legal bounds it is especially valuable in exception freedom proofs. For example, 
consider the source code in Figure 4. The variables I and J are declared to be of 
type ARP0_T. Thus the method will find abstract values for I and J which may 
be expressed using the following candidate invariant. Note that SPARK code 
assertions, including invariants, are annotated as — # assert. 

— #assert (I>=ARPQ_T’First and I<=ARPO_T’Last) and 
— # (J>=ARPQ_T’First and J<=ARPO_T’Last) ; 
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package PolishFlagPackage is 
subtype AR_T is Integer 
range 1 . . 4 ; 

type AC_T is (Red, White); 
type A_T is array (AR_T) 
of AC_T ; 

procedure PolishFlag(A : in out A_T) ; 
— # derives A from A; 
end PolishFlagPackage; 



package body PolishFlagPackage is 
procedure PolishFlag(A : in out A_T) 
is 

subtype ARP0_T is Integer 

range A’First . . A ’Last+l ; 

I , J : ARP0_T ; 

T: AC_T ; 
begin 

I : =ARP0_T ’ F irst ; J : =ARPQ_T’Last ; 

loop 

exit when I=J ; 
if A(I)=Red then 

I: =1+1; 
else 

J : =J-1 ; T : =A ( I ) ; 

A(I) : =A( J) ; A(J):=T; 
end if ; 

end loop; 
end PolishFlag; 
end PolishFlagPackage; 



Fig. 4. Sort two value array 



This invariant is required to prove exception freedom. Note that it is impossible 
to prove that a variable is within its type until it has been assigned a value, 
ruling out the candidate invariant property that T is inside its type AC_T. 

5.5 Method: For Loop Range 

Each SPARK for loop iterator must have a declared type. This type may be 
constrained by imposing an additional range restriction. For example, consider 
the source code in Figure 5. The loop iterator I is declared to be of type AR_T 
and is constrained to be inside a range from L to U. This inspires abstract values 
which may be expressed as the following candidate invariant. 

— #assert I>=L and I<=U; 

Note that the property that loop iterators are within their type, as asserted by 
the EXAMINER, is usually sufficient for exception freedom proofs. However, the 
more constrained property found here would likely assist a partial correctness 
proof. 

5.6 Method: Non-looping Code 

At the start of a SPARK subprogram an arbitrary variable X will either have its 
initial value (x~) or be undefined ( undef ). Following each assignment to X its 
value will change accordingly. Essentially it is straight forward to propagate the 
value of variables through non-looping code. 
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package FindPackage is 
subtype AR_T is Integer 
range 1 . . 10 ; 

subtype ARM0_T is Integer 
range 0 . . 10 ; 
type AC_T is 

range -1000.. 1000; 
type A_T is array (AR_T) 
of AC_T ; 

procedure Find(A: in A_T ; 

L,U: in AR_T; 

F: in AC_T; 

R: out ARM0_T) ; 
— #derives R from A,L,U,F; 
end FindPackage; 



package body FindPackage is 
procedure Find(A: in A_T ; 

L,U: in AR_T ; 

F: in AC_T; 

R: out ARM0_T) 
is 

begin 

R:=0; 

for I in AR_T range L..U loop 
if A(I)=F then 
R: =1 ; 
exit ; 
end if ; 
end loop; 
end Find; 
end FindPackage; 



Fig. 5. Find first index in array, between bounds, containing target 



For example, consider the source code shown in Figure 6. At the start of 
subprogram Clip v = v~ and r = undef. Entering the then branch of the 
outermost if statement yields r = I IT' First. Entering the else branch enters 
the innermost if statement. The then branch yields r = I T' Last while the else 
branch yields r = u~. As either branch of the innermost if statement may be 
taken a disjunction is required giving (r = I IT’ Last) W (r = v~). This is repeated 
for the outermost if statement giving (r = I IT' First) V ((r = I IT' Last) V (r = 
v~)). These abstract values may be expressed through the following candidate 
assertion. Note that as V is an import variable of mode in it can not be changed 
and thus implicitly refers to its initial value. 

— #assert (R=I_T’First) or C(R=I_T’Last) or (R=V)); 

However, where variables are assigned expressions involving variables, as in 
R:=V, it is often the case that conditional information can be exploited to con- 
strain the abstract values. For example, consider the disjunct r = v~ generated 
above. All that will be known about v is that it is inside its type. As v is declared 
as an integer this provides a weak constraint on the value of r. Where R : =V is en- 
countered it is known that ~>(v < FT' First) A~<(v > FT' Last). Using inequality 
reasoning this can be simplified to (v > FT' First) A (v < I IT' Last). Replacing 
v~ with this gives a more constrained abstract value following the outermost if 
r = FT' FirstW (r = I IT' Last V ((r > FT' First) A (r < FT' Last))) , which can 
be simplified to (r > I IT' First) A (r < FT' Last). This abstract value would be 
expressed using the following candidate assertion. 

— #assert (R>=I_T’ First and R<=I_T’Last) ; 

Consistently performing such reasoning for the general case would become diffi- 
cult. However, reasonable progress can be made by targeting variables occurring 
in assigned expressions and employing lightweight inequality reasoning. 
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package ClipPackage 
is 

subtype I_T is Integer 
range 1 . . 4 ; 

procedure Clip(V: in Integer; 

R: out I_T) ; 

— # derives R from V; 
end ClipPackage; 



package body ClipPackage is 
procedure Clip(V: in Integer; 

R: out I_T) 
is 

begin 

if V<I_T'First then 
R: =I_T 'First ; 
else 

if V>I_T’Last then 
R: =I_T’Last ; 
else 
R: =V; 
end if ; 
end if ; 
end Clip; 
end ClipPackage; 



Fig. 6. Clip from integer to more constrained type 



5.7 Method: Looping Code 

Looping code presents problems over non-looping code as the abstract values 
found for variables within the loop should be general enough to describe every 
iteration. We use recurrence relations to describe the value of a variable on an 
arbitrary iteration. Powerful tools exist to automatically solve certain classes of 
recurrence relations, e.g. MATLAB [31]. Although we have focused on PURRS [33] 
as we only require a generic recurrence relation solver we are not tied to PURRS. 

The transformations applied to a program variable in a loop are expressed as 
a recurrence relation, i.e. the value of a variable on the n th iteration is expressed 
in terms of variables on previous iterations, usually the (n— l) th iteration. Solving 
these recurrence relations produces an invariant equating the value of a variable 
on the n th iteration to an expression involving n. To extract usable properties 
from the solved recurrence relations it is necessary to eliminate this n. 

Solving a variable’s recurrence relation may require solutions to other recur- 
rence relations. For this reason the method is separated into sub-methods with 
the more immediate sub-methods being applied first. Note that the sub-methods 
are shown below in the order in which they are applied. 



Sub-Method: Unchanged: This targets variables that are unchanged inside 
a loop. Any import variables of mode in must remain unchanged throughout a 
subprogram. These are identified by examining the subprogram’s parameter list. 
Other variables must change inside the subprogram but may remain unchanged 
inside a loop. These are identified by finding no assignments to the variable 
inside the loop. 

For example, consider the source code shown in Figure 5. By examining the 
subprogram parameter list it is found that A, L, U and F are import variables of 
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mode in. Recurrence relations are calculated for the remaining variable R. The 
initial value of r is 0 and no assignments are made to r inside the loop (the only 
assignment to r takes place on the loop exit) . Thus the recurrence relation found 
for r is r( 0 ) = 0, r(„) = r(„_ i) which is solved as r(„) = 0. These abstract values 
may be expressed as the following candidate invariant. 

— #assert A=A and L=L and U=U and F=F and R=0; 

Note that the only descriptive property is R=0. However, by successfully solving 
all of the variables the loop analysis of this subprogram can now terminate. 



Sub-Method: Constant Change: It is common to modify a variable by a 
constant value in each iteration of a loop. These are identified by finding that 
every assignment to a variable occurs outside conditional statements and the 
assigned expressions only involve this variable and constant values. 

For example, in the running example of Figure 1, I is implicitly initialised to 
0 and the assignment statement I:=I+1 is implicitly seen after each iteration of 
the loop. This is expressed as the recurrence relation i( q) = 0,i( n ) = i(n- 1 ) + 1 5 
which is solved as ?'(„) = i( o) + n and reduced to ii n ) = n. As this abstract value 
contains n it can not yet be presented as a candidate invariant. 



Sub-Method: Variable Change: A variable may be modified by a variable 
amount in each iteration of a loop. This can occur in several cases including 
assigning to a variable inside a conditional statement and assigning a variable 
an expression which takes different values from an array. In such cases there is 
not sufficient information to describe the exact value of a variable on the n th 
iteration. Thus an approximation is made, generalising the search to finding the 
bounds of all possible values on the n th iteration. We model the extreme end 
points of these bounds using what we call extreme recurrence relations. 

For example, in the running example of Figure 1, R is initialised to 0 and 
the assignment statement R:=R+A(I) is seen within the then branch of the if 
statement which is conditional on A(I)>=0 and A(I)<=100. The recurrence re- 
lation for not entering the if statement is r( 0 ) = 0,r( n ) = r( n _ i), which is 
solved as r ( n ) = 0. However, the recurrence relation for entering the if state- 
ment, j-( o) = 0,T( n ) = r (n—i) + element(a,i), cannot be solved. The problem 
is that element(a , i) represents a variable change. This problem term is elim- 
inated by generalising to its extreme bounds. Exploiting context information 
reveals these bounds to be between r(„) = rt n - 1 ) + 0 and T( n ) = r(„_ i) + 100. 
Each of these can be solved and expressed as a range giving the abstract value 
( r (n) > 0) A (r( n ) < (n * 100)). Once again, as this abstract value contains n it 
can not yet be presented as a candidate invariant. 



Sub-Method: Counter Variables: During the execution of a loop the value 
of variables may change. Those variables found to monotonically increase or 
decrease by one are classified as counter variables. Counter variables are very 
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common and often key to understanding an algorithm, motivating their special 
classification. 

Counter variables can be identified by exploiting the abstract values found 
by the constant change and variable change sub-methods. For example, in the 
description of the constant change sub-method it was shown how the abstract 
value ?’(„) = n would be found for variable I in the running example of Figure 1. 
Although the presence of n prevents this from being presented as a candidate 
invariant, it is straight forward to determine that I is an increasing counter vari- 
able initialised at zero (as n can be thought of as an increasing counter variable 
initialised at zero). There would be little benefit in expressing this property as a 
program assertion. However, this information can be collected as program prop- 
erties and be exploited during proof planning. For example, in [23] the counter 
variable classification is instrumental in progressing an otherwise failed program 
proof. 



Sub-Method: Extracting Properties: Following the loop analysis it is neces- 
sary to post-process the solved recurrence relations into new abstract values that 
eliminate all references to n. This is achieved by replacing n with an expression 
in terms of the known program variables. 

For example, in the running example of Figure 1 the initial abstract values 
are i/ n \ = n and (rv„) > 0)A(r(„) < (?r*100)). The upper bound of?’ is expressed 
in terms of n, however, exploiting ?(„) = n, n is replaced by i giving the new 
abstract value (r( n ) > 0) A (j*( n ) < (i( n ) * 100)) which may be expressed as the 
following candidate invariant. 

— #assert (R>=0) and (R<=(I*100) ) ; 

Note that it is difficult to eliminate n in i( n \ = n as r is not described as an 
equality with n. This failure means that if an invariant property describing I 
is required then a suitable abstract value discovered from another method must 
be used instead. Further note that although the loop analysis does not suggest 
a candidate invariant property for I it does successfully classify it as a counter 
variable. 



5.8 Method: Loop Guards 

The loop analysis involves recurrence relations, expressing constraints on vari- 
ables on the n th iteration. The loop exit could be modeled by constraining the 
range of n and analysing the recurrence relations associated with variables. How- 
ever, such an approach can be quite complicated and often unnecessary. Thus 
we instead consider the loop exit as a special case distinct from the recurrence 
relation analysis. We focus on finding properties that describe relationships be- 
tween variables in the loop guard. In particular we check to see if an inequality 
relationship holds between these variables. 

The loop guard is significant as its negation becomes available in the loops 
iteration VCs. This is the only property that constrains loop iterations and 
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thus must be exploited to show that monotonically increasing (or decreasing) 
variables do not increase (or decrease) forever and exceed their legal bounds. 

For example, in the running example of Figure 1 it must be proved that 
I<=AR_T’Last is invariant, i.e. that I does not exceed the upper bound of its 
type. This loop implicitly has a loop guard of the form I=AR_T’Last. Thus 
the induction hypothesis, i < ARIF' Last, and the negation of the loop guard, 
->(i = ARAL' Last ), are hypotheses in the loop iteration VCs. Crucially, these 
can be combined to provide a single inequality constraint i < AR_T' Last. As i is 
an increasing counter variable the induction conclusion will take the form i + \ < 
ARAL' Last which is trivially true given the inequality constraint hypothesis. 

However, cases exist where the negation of the loop guard is not sufficiently 
strong to support such a proof. For example, consider the source code in Figure 4. 
Assume the following loop invariant, discovered in §5.4, has been added to prove 
that I and J do not exceed their type. 

— #assert (I>=ARP0_T’First and I<=ARP0_T’Last) and 
— # (J>=ARP0_T’ First and J<=ARP0_T’Last) ; 

The loop guard is I=J, introducing the hypothesis -i (i = j) during loop iteration. 
Knowing that i and j have different values does not constrain the bounds of i 
and j. The counter variable sub-method reveals that I is an increasing counter 
variable, J is a decreasing counter variable and that I starts below J. As the loop 
exits at I=J, I can never exceed J, discovering the candidate invariant property 
i < j. Adding this invariant property introduces the new hypothesis i < j into 
the loop iteration VCs. This can now be combined with the negation of the loop 
guard to introduce the inequality constraint hypothesis i < j. This is sufficiently 
strong to prove that both I and J remain within the bounds of their type. 

6 Patching Proof Failure 

We return to our running example of Figure 1 and proving the RTC VC for the 
then-branch as shown in Figure 2. Our initial proof plan in §4.3 failed with the 
transitivity critic requesting additional hypotheses corresponding to the schema 

(r > A) A (r < B) . 

This failure activates program analysis of the relevant subprogram generating 
a collection of program properties. These properties are searched for a suitable 
candidate invariant constraint on r, guided by the schema above. Such an in- 
variant was discovered in §5.7 and is repeated below. 

— #assert (R>=0) and (R<=(I*100) ) ; 

Adding this invariant leads to revised RTC VCs, adding the following two hy- 
potheses to the RTC VC shown in Figure 2. 

H6 : r >= 0 . 

H7 : r <= loop 1 i * 100 . 
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7 Planning the Revised VCs 

7.1 Loop Invariant Methods 

As illustrated above, it is often the case that an invariant must be strengthened 
before an exception freedom proof can be completed. The stronger invariant 
properties must be proved. The proof planner tackles loop invariant VCs using 
the ripple method [2,6]. Although space precludes further discussion we note that 
proving loop invariants via the ripple method has been previously investigated 
and reported [24,34,25]. For example, in the running example of Figure 1 the 
strengthened invariant results in two loop invariant VCs, neither of which are 
automatically discharged by the SIMPLIFIER. However, by proof planning using 
the ripple method these proofs can be automated. 

7.2 Revisiting the Exception Freedom Methods 

We now consider the methods introduced in §4.1 in more detail. Recall that 
proving exception freedom involves showing that a variable does not violate its 
legal upper and lower bounds. Let the general value of a variable be denoted by 
the term T(Vi, . . . , V n ), where Vi, 1 < i < n, denote variables. Further let L and 
U denote the lower and upper constants of a bound. Thus a variable’s lower and 
upper bound checks give rise to goals of the form in (1) and (2) respectively. 

TO ,...,V n )>L (1) 

T{V u ...,V n )<U (2) 

Although we focus on the upper bound case (2), the same general pattern of 
proof is also applicable to the lower bound case (1). The proof context associated 
with (2) should contain hypotheses expressing the upper bounds of V 

V < Ui . (3) 

Note that the absence of such hypotheses triggers the transitivity critic which 
aims to introduce the missing hypotheses by exploiting our program analysis. 
The first step involves the transitivity method, reducing (2) to give 



{T(V 1 ,...,V n )<X 1 )A{X 1 <U) . (4) 

The introduction of the meta-variable Xi prepares the way for the decomposition 
of T(V i, . . . , V n ). The second step calls the decomposition method to decompose 
T(V i, . . . , V n ). This draws upon a collection of substitution axioms for inequali- 
ties. The aim of this method is to express the left hand side conjunct of (4) as 
a conjunction of inequalities of the form 

Vi < Xj . (5) 

Note that the complete decomposition of T{V \, . . . , V n ) may require the applica- 
tion of multiple substitution axioms. The third step calls the fertilise method to 
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match the decomposed inequalities against the inequality hypotheses. Matching 
(5) against (3) instantiates X y to IJj . This has the effect of instantiating the right 
hand side conjunct of (4) to give 

T(U u ...,U n ) <U. (6) 

The fourth and final step involves the elementary method, simplifying (6) such 
that it can be trivially discharged by the PROOF CHECKER. 

The key to the proof plan is the transitivity method as described in Figure 3. 
Note that the transitivity method introduces a first-order meta- variable into the 
goal structure that is incrementally instantiated during subsequent proof plan- 
ning steps. This use of meta-variables is known as middle-out reasoning [5] and 
has been used effectively in guiding proof search within the context of program 
synthesis [30,35], proof patching [20,21,22] and loop invariant discovery [24,34, 
25]. 

7.3 Successful Proof Plan 

We now return to proving the then-branch of the code in Figure 1 following the 
patch of an invariant. Once again, we focus on the goal of proving C4 

(r + element(a,i)) < integer Jast , (7) 

noting that the proof context includes the two hypotheses H7 and H5, 

(r <i* 100) A (element(a, i) < 100) . (8) 

The proof planning begins with an application of the transitivity method, rewrit- 
ing (7) to a conjunction 

((r + element(a,i)) < X\) A (Xi < integer Jast) . (9) 

The decomposition method searches for a substitution axiom involving <, finding 
the rewrite rule 



(W + X) < (Y+ Z) => (W < Y) A (X < Z) (10) 

which is applied to (9) giving 

((r < X 2 ) A ( element(a,i ) < -X3)) A ((X 2 + X 3 ) < integer Jast) . (11) 

Note that as a side-effect of applying (10), X\ has been instantiated to X 2 +X 3 in 
(11). Given (8), the fertilise method applies to the conjuncts on the left hand side 
of (11) resulting in X 2 and X 3 being instantiated to i * 100 and 100 respectively. 
The remaining goal takes the form 

((i * 100) + 100) < integer Jast . 

Given that integer Jast has a known concrete value this goal is trivial and can 
be discharged by the elementary method. 
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8 Related Work 

Probably the first system to prove exception freedom was the RUNCHECK verifier 
[18]. RUNCHECK operated on Pascal programs, employing a number of heuristics 
to discover invariants and tackling RTC VC proofs with an external theorem 
prover. One of its heuristics involved the calculation of recurrence relations as 
change vectors, ignoring program context and collecting transformations made 
to variables. These change vectors were subsequently solved using a few rewrite 
rules that targeted common patterns. Our approach has a tighter integration 
between theorem proving and program analysis. In addition, our program anal- 
yser solves recurrence relations using a powerful recurrence relation solver tool. 
Further, our program analysis exploits program context and approximates to 
ranges where equality solutions can not be found. 

The use of recurrence relations in generating loop-invariants was first re- 
ported by Elspas et al [13] and was also used by Katz and Manna [29]. Although 
the limits of recurrence relations as a basis for generating loop-invariants are 
well known [8], they have proved to be very useful for our niche application. 

Recently there has been renewed interest in approaches that employ theorem 
proving to strengthen program development. The focus tends to be on finding er- 
rors rather than proving correctness. For example, esc/java [17] is an extended 
static checker for Java. Like SPARK, esc/java requires program annotations. 
Houdini [16] is able to automatically generate many of the annotations required 
by esc/java using predicate abstraction. 

There exists systems that employ program analysis to pinpoint unfavourable 
behaviour. These systems are typically formulated inside the abstract interpre- 
tation framework [10]. By observing this framework the program analysis will 
ensure correctness by allowing for approximate results. The most noteworthy sys- 
tems are MERLE [38] and POLYSPACE [32]. Although these systems do not target 
proof, their results might be used to assist a formal proof. Rather than use anno- 
tations these systems gain constraints on variables by analysing a program in its 
entirety. This process can be computationally expensive and requires a complete 
program for input. As our program analysis targets individual subprograms it is 
fairly cheap to perform and is applicable early in program development. Further, 
by avoiding the abstract interpretation framework we have the flexibility to im- 
plement heuristic based program analysis techniques. As we treat our program 
analysis as an oracle that guides search for a formal proof, we can adopt this 
approach without sacrificing correctness. 



9 Progress and Future Work 

Our NUSPADE tool has been prototyped as separate components. The proof plans 
presented here have been implemented within the CLAM proof planner [7]. Note 
that this prototype does not support the extraction of a customised tactic from 
discovered proof plans. The program analysis has been prototyped in a system 
with a limited SPARK parser. This is sufficient to explore the program analysis 
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methods. Work is underway on completing the NUSPADE system. Currently we 
have developed a suitable proof planning infrastructure in Prolog and are build- 
ing a stronger program analysis system, exploiting the STRATEGO [37] program 
transformation tool. 

Using our prototype systems we have successfully demonstrated the appli- 
cability of our technique on a collection of isolated subprograms. These sub- 
programs are representative of the kinds of subprograms that are seen within 
a high integrity software system. The next step is to tackle proof of exception 
freedom for an entire industrial strength high integrity software system. We also 
envisage a comparative study between our approach and non-theorem proving 
techniques, such as MERLE and POLYSPACE. It may be found that such systems 
can be packaged as additional program analysis oracles for use in our approach. 



10 Conclusion 

Building upon the SPARK toolset, we have developed an approach for increas- 
ing the automation of exception freedom proofs. Our approach is formulated 
within the proof planning framework. Under certain patterns of failure, critics 
are invoked which in turn appeal to a program analysis oracle. This oracle aims 
to discover program properties that patch the failed proof, allowing the proof 
planning to progress. 

Our approach demonstrates that program verification can be tackled on more 
than one front. By integrating the distinct static analysis techniques of proof 
planning and program analysis a more capable automatic program verification 
system can be can be constructed. 
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Abstract. Recent work on combining CSP and B has provided ways 
of describing systems comprised of components described in both B (to 
express requirements on state) and CSP (to express interactive and con- 
troller behaviour). This approach is driven by the desire to exploit exist- 
ing tool support for both CSP and B, and by the need for compositional 
proof techniques. This paper is concerned with the theory underpinning 
the approach, and proves a number of results for the development and 
verification of systems described using a combination of CSP and B. In 
particular, new results are obtained for the use of the hiding operator, 
which is essential for abstraction. The paper provides theorems which 
enable results obtained (possibly with tools) on the CSP part of the de- 
scription to be lifted to the combination. Also, a better understanding 
of the interaction between CSP controllers and B machines in terms of 
non- discriminating and open behaviour on channels is introduced, and 
applied to the deadlock-freedom theorem. The results are illustrated with 
a toy lift controller running example. 



1 Introduction 

Morgan’s failures/divergences semantics for event systems [Mor90] enables the 
various CSP semantics to be given to B machines. These CSP semantics allow 
machines to be treated as CSP components within a concurrent system, and 
we can combine them with other CSP components using architectural operators 
such as parallel composition and abstraction. 

Recent work [TreOO] has considered the interaction between a particular kind 
of B machine and a controller written as a (recursive) sequential CSP process. 
An important requirement of a controller for a machine is that it should invoke 
machine operations only within their preconditions. Previous results [TreOO] have 
identified conditions sufficient to guarantee P || M to be divergence- free for a 
controller P and machine M , which ensures this important property. These re- 
sults require identification of a control loop invariant (CLI) on the state of the 
B machine M , which must be true on every recursive call. This is established by 
considering the semantics of the B operations as they are called within the con- 
troller, and essentially computing the weakest precondition required to establish 
the CLI. 

In combining communicating B machines, we use a particular architecture 
[ST02b] to restrict the interaction between components, by ensuring that each 
B machine interacts only with its own controller. A system will be structured as 
a collection of B machines Mi , ..., M n , each with its own CSP controller process 
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Fig. 1. A CSP and B combined system architecture 

Pi , ..., P n . A controlled component is the parallel combination of a controller and 
its B machine, of the form P || M . 

Each Mi is under the control of the corresponding Pi, and the Pi s can also 
interact with each other. This architecture is illustrated in Figure 1. Interaction 
across the system can occur only between the CSP processes. This approach 
enables compositional verification, whereby we are able to verify properties of the 
entire system by obtaining results about smaller structures within the system. 
In particular, both CSP and B already have mature tool support which can be 
used to verify the components. 

The model-checker FDR [For97] performs model-checking on systems de- 
scribed in CSP, and is therefore suitable for analysing the controllers, individ- 
ually and in combination. The paper provides theorems which enable results 
obtained (possibly with tools) on the CSP part of the description to be lifted to 
the combination 1 . We obtain a number of theorems in the various CSP semantic 
models. 

In practice, we find that it is often the case that a property holds in a com- 
bined system for reasons associated with the state within the B components. In 
this case, the CSP controller descriptions need to be augmented with the rel- 
evant state information. This paper also provides theorems which support the 
required manipulations of CSP controllers. In this paper, we provide informal 
explanations of the theorems, but for reasons of space cannot include the proofs. 
Instead, a fuller version of this paper [ST02a] gives proofs of all the theorems 
and lemmas. 



2 Background 

2.1 CSP Events 

CSP processes are defined in terms of the events that they can and cannot do. 
Processes interact by synchronising on events, and the occurrence of events is 
atomic. The set of all events is denoted by E. 

Events may be compound in structure, consisting of a channel name and 
some (possibly none) data values. Thus, events have the form c.v \...v n , where c 

1 The FDR checks discussed in this paper are available at 
http : //www . cs .rhul . ac . uk/research/f ormal/ Steve/ code/lif ts . f dr 2 
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is the channel name associated with the event, and the i \ are data values. The 
type of the channel c is the set of values that can be associated with c to produce 
events. 

For example, if trans is a channel name, and N x Z is its type, then events 
associated with trans will be of the form trans. n.z, where n £ N and ztZ. For 
example, trans. 3. 8 is one such event. 

A partial event , or (following [Sca98]) partially completed datatype value is a 
channel name together with some values, but not necessarily all. For example, 
trans . 3 is a partial event. Any channel is a special case of a partial event. 

Given a set of partial events PE, we can define the set of events {| PE |} 
which are the completions of events in PE, as follows: 

{| PE |} = {p.w | p £ PE A p.w £ A} 

We use alphabetised CSP, so every process has an alphabet, which is the set of 
events whose occurrence requires its participation. The alphabet of a process P 
is denoted a(P). For the purposes of this paper we will require that the alphabet 
of any process is given by a set of channels C , so that a(P) = {| C |}. 



2.2 CSP Controllers 

A controller for a B machine is a particular kind of CSP process. To interact 
with the B machine, it makes use of control channels which have both input and 
output, and provide the means for controllers to synchronise with B machines. 
For each operation w < — e(v) of a controlled machine with v of type Ti n (e) 
and w of type T out {e) there will be a channel e of type Ti„(e) x T out (e), so 
communications on e are of the form e.v.w. 

Controller descriptions may also include assertions about the values of vari- 
ables they are using. These are incorporated in CSP either as blocking assertions 
(which block if the assertion is false) or as diverging assertions (which diverge if 
the assertion is false), depending on the role they play in verification. 

When we talk about a CSP controller P we mean a process which has a given 
set of control channels C. The controlled B machine will have exactly {| C |} as 
its alphabet: it can communicate only on channels in C . 



Controller syntax. Controllers are generated from the following subset of the 
CSP syntax, as discussed in [ST02b]. 

P a — > P\clx — > P\d\v —X P\e\v?x{E(x)} —X P\e\vlx{E{x)) —X P\ 

Pi D P 2 1 P\ n P 2 1 n x{E(x) P | if b then P 1 else P 2 \S(p) 

where a and is a synchronisation event, c is a communication channel accept- 
ing inputs, d is a communication channel sending output values, e is a control 
channel, a; is a data variable, v is a data value, E(x) is a predicate on x (it may 
be elided, in which case it is considered to be true), b is a boolean expression, 
and S(p) is a process expression. 
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The process a — > P is initially prepared to engage in an a event, after which 
it behaves as P. The input clx — > P is prepared to accept any value x along 
channel c, and then behave as P (whose behaviour can be dependent on x). The 
output d\v P provides v as output. The operation call e\vlx{E(x)} —> P 
is an interaction with an underlying B machine: the value v is passed from the 
process as input to the B operation, and the value x is accepted as output from 
the B operation. If x meets the condition E( x) then the process behaves as P. 
If x does not meet the condition then the process diverges. On the other hand, 
e\vlx{E[x)) —> P only allows e.v.x if E(x), otherwise the event is blocked. 
Behaviour subsequent to e.v.x is that of P. 

The external choice process Pi □ P 2 is initially prepared to behave either as 
P\ or as P 2 , and the choice is resolved on occurrence of the first event. Binary and 
general internal choice are possible, though not used in the example presented 
here. The conditional choice if b then Pi else P 2 behaves as Pi or P 2 depending 
on the evaluation of the condition b. The process expression S(p) expresses a 
recursive call. Finally, processes can be defined using (recursive) definitions of 
the form S(p) = P. 



2.3 CSP Semantic Models 

There are three semantic models used in this paper: the Traces model, the Stable 
Failures model, and the Failures/Divergences model. We introduce the relevant 
features of them here. Full details of these models can be found in [Ros97,Sch99]. 
Traces. A trace is a finite sequence of events. A sequence tr is a trace of a 
process P if there is some execution of P in which exactly that sequence of 
events is performed. The set traces(P) is the set of all possible traces of process 
P. The traces model for CSP associates a set of traces with every CSP process. 
If traces (P) = traces (Q) then P and Q are equivalent in the traces model, and 
we write P =t Q- 

Stable Failures. A stable failure is a pair ( tr,X ) consisting of a trace tr and 
a set of events X. Such a pair is a stable failure of a process P if there is some 
execution of P on which tr is the sequence of events performed, reaching a state 
in which all events in X can be refused, and also no internal progress is possible. 
The set ST [[P]] is the set of stable failures of P. The stable failures model 
for CSP associates a set of stable failures, and a set of traces, with every CSP 
process. If ST [[P]] = ST [[Q]] and also traces(P) = traces(Q) then P and Q are 
equivalent in the stable failures model and we write P ~SF Q- 
Failures and Divergences. A divergence is a finite sequence of events tr. Such 
a sequence is a divergence of a process P if it is possible for P to perform an 
infinite sequence of internal events (such as a livelock loop) on some prefix of tr. 
The set of divergences of a process P is written T> [[P]] . 

A failure is a pair ( tr,X ) consisting of a trace tr and a set of events A. It is 
a failure of a process P if either tr is a divergence of P (in which case X can be 
any set), or ( tr,X ) is a stable failure of P. The set of all possible failures of a 
process P is written T [[P]]. If V [[P]] = V [[Q]] and T [[P]] = T [[Q]] then P and 
Q are equivalent in the failures-divergences model, written P =fd Q- 
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The different models are used to analyse CSP systems with respect to dif- 
ferent properties. This paper is concerned with the failures-divergences model, 
which is used to check for liveness properties such as divergence-freedom. If a 
system description includes the possibility of divergence (for example, if it in- 
cludes internal events), then it is necessary to use the failures-divergences model 
to check for divergence-freedom. 

An important relationship between the stable failures model and the failures 
divergences model is that if a process is divergence-free (i.e. its set of divergences 
is empty), then its failures are the same as its stable failures. This is captured 
in the following theorem: 

Theorem 1. IfV[[P}} = {}, then T [[P]] = ST [[P]]. 

This theorem is useful because it allows us to carry out analysis in the stable 
failures model, which is generally easier and more efficient, and to establish 
results which remain valid in the failures-divergences model. For example, once 
it has been established that a process P is divergence- free, then to check that 
it is deadlock-free (i.e. that ( tr,a(P )) cannot be a failure of P for any tr), it is 
sufficient to check this in the stable failures model (that (tr,a(P)) cannot be a 
stable failure). The model-checker FDR [For97] can carry out divergence-freedom 
and deadlock-freedom checks mechanically. There are also CSP theorems (for 
example, Theorem 3 in this paper) for establishing that a process P is divergence- 
free. 



2.4 CSP Semantics for B Machines 

Morgan’s CSP-style semantics [Mor90] for event systems enables us to define 
such semantics for B machines. A machine M thus has a set of traces T[[M]], a 
set of failures T [[M]], and a set of divergences V [[M]]. A sequence of operations 
(ei, e 2 . . . e n ) is a trace of M if it can possibly occur. This is true precisely when 
it is not guaranteed to be blocked, or in other words it is not guaranteed to 
achieve false. In wp notation we write ~^wp(e\\ e 2 ', ■ ■ ■ ; e ni false), or in Abstract 
Machine Notation -i([ei; e2; ...; e n ]false). (The empty trace is treated as skip). 
A sequence does not diverge if it is guaranteed to terminate (i.e. establish true). 
Thus, a sequence is a divergence if it is not guaranteed to establish true, i.e. 
i([ci; e2; ...; e n \true). Finally, given a set of events X, each event e € X 
is associated with a guard g e . A sequence with a set of events is a failure of 
M if the sequence is not guaranteed to establish the disjunction of the guards. 
Thus, (ei; e2; ...; e n , X) is a failure of M if — >[ei; e2; ...; e n ](V eg x ffe)- More 
details of the semantics of B machines can be found in [TreOO] 

Morgan does not give a stable failures semantics for action systems. We 
will define the stable failures 6uF[[M]] for a machine M in terms of its failures 
divergences semantics, as follows: 

Definition 1. The stable failures of a B machine are defined as follows: 

ST [[M]] = {(tr, X) | (tr, X) e T [(M)] A tr (£V [[M])} 
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MACHINE i_Lif t 

VARIABLES i_floor 
INVARIANT i_f loor : NAT 

INITIALISATION i_floor := 0 
OPERATIONS 

i_inc(nn) = 

PRE nn : NAT1 

THEN i_floor := i_floor + nn 
END; 

i_dec = 

PRE i_floor > 0 

THEN i_floor := i_floor - 1 

END; 

bb < — i_isZero = 

IF i_floor = 0 
THEN bb := TRUE 
ELSE bb := FALSE 
END 

END 



i-LiftCtrl = 

i—uply i—inc\y i—LiftCtrl 

□ i-downly — » i_DOWN (y) 

□ i-ground i -LOWER 

i-DOWN (n) = 
if n = 0 
then i_LiftCtrl 
else i_isZero?bb — > 
if (bb = TRUE ) 
then i_LiftCtrl 

else i—dec i-DOWN (n — 1) 

i-LOWER = 
i_isZero7bb — > 



if (bb = TRUE ) 
then i_LiftCtrl 
else i—dec — » i-LOWER 

Fig. 2. A Lift machine i_Lift and its controller i_LiftCtrl 



Observe that with this definition, Theorem 1 also holds for B machines M . 

We have a technique [Tre00,ST02b], based on control loop invariants, for es- 
tablishing that a combination P || M is divergence- free. In other words, previous 
results provide a means to establish that T> [[P || M]] = {}. This paper is not con- 
cerned with that technique. Rather we are concerned with composing together a 
number of Pi || M t pairs once we have established that T> [[Pj || M;]] = {} for each 
pair. Hence a number of the theorems in this paper will include an assumption 
that V [[Pi || Mi]] = {}. The assumption in particular cases can be discharged 
using the control loop invariant technique. 



3 A Motivating Toy Example: A Lift Controller 

As motivation for the results presented in this paper, we consider a toy example 
of a collection of lift machines described in B, controlled by CSP controller 
processes. We will indicate the use of the theorems presented later in the paper. 
An individual lift is given in Figure 2. It describes a particular lift, indexed by 
i. We will then go on to define a system consisting of a collection of such lifts. 

3.1 Individual Lifts 

The Lift machine provides three operations: i_inc(nn) which moves the lift up 
nn floors, i_dec which moves the lift down one floor, and a query operation 
i_isZero which indicates whether or not the lift is on the ground floor. 
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i-up i-down i_ground 




Fig. 3. The controlled lift system 

The CSP controller is also given in Figure 2. It interacts with a user through 
the events i_up, i-down , and i_ground, and controls the lift accordingly: 

— on i_up.y , it calls i_inc and moves the lift up y floors. 

— on i_down.y, it calls i_dec y times or until it reaches the ground if this is 
sooner. 

— on i_ground , it is required to move the lift to the ground floor. To do this, it 
repeatedly checks (using i_isZero) whether the lift is on the ground floor, 
and if not then it moves the lift down a floor with i_dec. 

We are firstly interested in each controlled lift combination 

i-LiftSys = (i_Lift || i_LiftCtrl) \ {| i_inc, i_dec , i_isZero |} 

which is pictured in Figure 3. We require as a minimum that this combination 
is deadlock-free and divergence- free. 

These properties are apparent in this simple example. Deadlock-freedom is 
immediate because the B machine is always willing to engage in any event re- 
quired by the controller, and the controller itself is either waiting for an interac- 
tion from its environment or else ready to call a controller operation. Divergence 
could arise either (i) from a B operation being called outside its precondition, or 
(ii) from an infinite sequence of internal events. In the case of (i), the only oper- 
ation with a non-trivial precondition is i_dec, and the controller is constructed 
so that i_dec is only ever called when the lift is not at floor 0. In the case of 
(ii), the lift will eventually reach the ground floor and so an infinite sequence of 
calls of i_dec cannot occur. 

In more complex examples the properties may not be so apparent, and it 
would be useful to be able to apply analysis tools to carry out model-checking 
on the combined system. However, no tools currently exist which can analyse a 
combination of B and CSP descriptions, so instead we analyse the descriptions 
separately and combine results. In particular, for considering properties such 
as deadlock and livelock we would aim to apply a tool such as FDR [For97] 
to the CSP part of the description, and deduce results about the controlled 
combination. In particular, once it has been established that the controller does 
not call operations outside their precondition, then the aim is that all deadlocking 
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i-LiftCtrl2(f) = 

i-up?y — » i-ind.y — > i-LiftCtrl2(f + y) 

□ i-downly i-D0WN2(f , y) 

□ i-ground i-LOWER2(f) 

i-L0WER2(f) = 

i-isZero? bb [{bb = TRUE / = 0}] -»• 

if (66 = TRUE) 
then i_LiftCtrl2(f ) 
else i_dec — > i-LOWER2(f — 1) 

Fig. 4. The controller with diverging assertions 

and divergent behaviour is essentially contained in the controller and can be 
identified without further reference to the B machine. 

It has previously been established [ST02b] that, under appropriate condi- 
tions, the deadlock-freedom of a controller P implies the deadlock-freedom of a 
controlled combination P || M. This result appears in this paper as Theorem 2 
in Section 4. 

We also establish in this paper (Theorem 3 in Section 5) that, under appro- 
priate conditions, if P \ E is divergence- free, then so too is ( P || M) \ E. 

These two theorems are exactly what is required. We have only to check that 
i Lift Ctrl is deadlock- free to deduce the same for i-Lift.Sys. And we have only 
to check that i-LiftCtrl \ {| i-inc , i-dec , i-isZero |} is divergence-free to deduce 
this for i-Lift.Sys. These are both checks that are easily done using FDR. 

However, the second check turns out not to be correct. The description of 
% LiftCtrl \ {| i-inc, i-dec, i-isZero |} in fact contains a divergence arising from 
the infinite sequence ( i-ground , i -is Zero. false, i-dec, i -is Zero. false, i-dec, . . .) of 
i -Lift Ctrl. It is the machine i—Lift that ensures that this cannot occur — but 
that machine was not included in the FDR analysis. 

The problem is that some of the control flow is dependent on the state in- 
formation maintained in the B machine, and so the useful theorems we have 
available are not directly applicable. We need to include the relevant state in- 
formation in the description of the CSP controller. We do this by introducing 
a new variable /, and also introducing the expectation that the value true will 
be received on channel i—isZero exactly when f = 0. This is included as an as- 
sertion, as shown in Figure 4. It is straightforward to show that i-Lift.Ctrl2(0) 
is an appropriate driver for i_Lift (using control loop invariant / = i_floor 
which relates the CSP state to the state of the B machine). The proof that 
i-LiftCtrl2( 0) || i-Lift has no divergences involves establishing the truth of the 
assertion for the input bb on i-isZero. 

Introducing a diverging assertion means that i-LiftCtrl2(0) trivially has a 
divergence (i.e. the behaviour when the assertion is not met), so it is not ap- 
propriate to check i-LiftCtrl2( 0) \ {| i-inc, i-dec, i-isZero |} for divergence- 



i-DOWN2(f,n) = 
if n = 0 

then i_LiftCtrl2(f) 
else i_isZerolbb 

[{66 = TRUE of 

if (66 = TRUE) 
then i_LiftCtrl2(f) 
else i-dec — » 

i-DOWN2(f - 1, n - 1) 
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i-LiftCtrl3(f) = 

i-uply — » i-inc\y — > i-LiftCtrV3(j + y) 

□ i-downly i-DOWN3(f, y) 

□ i-ground —¥ i-LOWER3(f) 

i-LOWER3(f) = 

i-isZero? bb [{bb = TRUE / = 0)] -> 

if (66= TRUE) 
then i-LiftCtrl3(f) 
else i_dec i-LOWER3(f — 1) 

Fig. 5. The controller with blocking assertions 

freedom. However, in the context of i—Lift. we know the assertion will always be 
true, so we may replace the diverging assertion by a blocking one, and yield a 
controller with the same behaviour in the context of i—Lift. The only difference 
is that this controller blocks rather than diverges when the assertion is false, and 
since the assertion is never false in the context of i—Lift., the resulting behaviour 
is the same. This transformation is justified by Corollary 1 (given at the end of 
Section 5). Thus, we obtain a variant i—Lift,Ctrl3(0) of the controller, given in 
Figure 5, such that i-LiftCtrl3( 0) || i-Lift. =fd i-LiftCtrl2(0) || i_Lift. 

Now we have a transformation of the controller which is divergence-free 
when the internal events are hidden: i-LiftCtrl3(0) \ {| i-inc, i-dec, i-isZero |} 
is divergence-free, and this can be checked using FDR (given a bound on 
the number of possible consecutive i-up events). So we can conclude that 
(i-LiftCtrl 3(0) || i—Lift) \ {| i-inc, i-dec, i-isZero |} is divergence- free. 

Now Corollary 1 also allows the assertions of i-LiftCtrl2( 0) to be dropped 
completely, resulting in a controller whose behaviour does not depend on the 
value of the parameter / at all, and which is therefore equivalent to i—LiftCtrl . 
This transformation is discussed in more detail in [ST02a]. We have therefore 
now established divergence-freedom of the original combination ( i_LiftCtrl || 
i—Lift ) \ {| i-inc, i-dec, i-isZero ]}. 

To sum up: we identified two new controllers which are equivalent in the 
presence of i—Lift to the original controller i—LiftCtrl, and which are each used 
in a different part of the proof. 

i-LiftCtrl2( 0) || i-Lift =fd i~LiftCtrl3( 0) || i-Lift =fd i—LiftCtrl || i-Lift 

— The combination i-LiftCtrl2(0) || i-Lift can be shown to be divergence-free 
using techniques from [ST02b], 

— i-LiftCtrl3( 0) \ {| i-inc, i-dec, i-isZero |} is divergence- free, and so 
(i-LiftCtrl3( 0) || i-Lift) \ {| i-inc, i-dec, i-isZero |} is divergence- free. 

— And i_Lift Ctrl2( 0) || i-Lift is equivalent to the original i-LiftCtrl || i-Lift. 

These results together establish the required result: that the original combination 
( i-LiftCtrl || i-Lift.) \ {| i-inc, i-dec, i-isZero |} is divergence- free. The state 



i-DOWN3(f,n) = 
if n = 0 

then i_LiftCtrl3{f) 
else i_isZerolbb 

[(66 = TRUE^f 

if (66 = TRUE ) 
then i_LiftCtrl3(f) 
else i-dec — » 

i-DOWN3(f - 1, n - 1) 
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bottom req 




Fig. 6. The complete system Lifts 



information was introduced into the controller purely to enable the verification 
to take place, and can be removed once the result has been established. 

We also deduce that ( i-LiftCtrl || i-Lift) \ {| i-inc,i-dec,i-isZero |} is 
deadlock- free. This follows from deadlock- freedom of i LiftCtrl || i-Lift. 



3.2 A Collection of Lifts 

We will now combine the lifts into a single system together with a Dispatch and 
DispatchCtrl component which manages requests for lifts from buttons on the 
various floors. When a request for a lift is made from a particular floor, only one 
of the lifts needs to be sent. An example architecture made up of four lifts is 
pictured in Figure 6. 

The Dispatch machine contains some algorithm for deciding which lift should 
be sent to a particular floor. It has an operation ii, nn, dd < — send(ff). On input 
of the floor ff to send a lift to, it provides as output the lift ii to be sent, the 
number of floors nn and the direction dd that lift ii will need to travel (as 
computed by Dispatch). Dispatch has another operation reset , which is called 
when all lifts return to the ground floor. The particular details of Dispatch are 
not relevant to this example and will not be given here. 

The DispatchCtrl controller accepts requests along channel req: an input 
reqlx is a request for a lift to go to floor x. It makes use of the Dispatch machine 
to decide which lift to allocate, and then sends the appropriate instruction to 
the relevant lift. The controller can also accept an instruction bottom to return 
all lifts to the ground floor. It is defined as follows: 

DispatchCtrl = reqlx — > sendlxl il nl d —> if d = ascend 

then i_up\n — > DispatchCtrl 
else i_down\n — > DispatchCtrl 
□ bottom —> 1-ground 2-ground — > 3-ground 

—> d-ground — > reset DispatchCtrl 
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Our overall system is then composed of the controlled lift components Lifts = 
|| J^i-LiftCtrl || i_Lift,) interacting with the DispatchCtrl || Dispatch com- 
ponent, and with all events apart from req and bottom internal: 

(|| ( i-LiftCtrl || i—Lift ) || ( DispatchCtrl || Dispatch )) \ Int 

Int = Uifli _inc, i-dec , i_isZero, i_up , i_doum, i_ground} U {| send, reset |} 

We will see in Section 6 that this system is deadlock- free and divergence-free. 

4 Deadlock-Freedom 

This section introduces two new properties concerning process behaviour on 
channels: open on possible inputs, and non- discriminating. These are the key 
properties exhibited by B machines and CSP controllers respectively. As we 
shall see, considering components in terms of these properties enables many of 
the results from Sections 4 and 5 concerning individual controlled components to 
be lifted to interacting collections of controlled components in Section 6. They 
also enable easier proofs of previously established results such as Theorem 2 in 
this section. 

An essential requirement for controlled components is deadlock- freedom. This 
is easily checked in FDR, but only for processes that are expressed in CSP. Thus, 
we aim to establish a theorem that allows the deadlock- freedom of P || M to be 
deduced from deadlock-freedom of P (which can then be checked using FDR). 

In general, parallel composition does not preserve deadlock- freedom. Fortu- 
nately, in the case of CSP controllers and B machines, we are able to identify 
conditions which ensure that the processes involved interact on their common 
channels in a particular way, ensuring that introducing a B machine cannot 
introduce any new deadlocks. In other words, any deadlocks possible for the 
controlled component P || M must already have been possible in P. 



Open on possible inputs. The required property of the B machine is that 
it should always be able to accept any input for any operation, and be able to 
provide some output. The need for this property is precisely why only machines 
with non-blocking operations are permitted. If a machine meets this property 
then we will say it is open on the particular operations and inputs. 

In CSP terms, this is defined formally for CSP processes Q as follows: 

Definition 2. A process Q is open on a set of partial events PE if, given any 
( tr,X ) £ SflQl and e £ PE, there is some w such that e.w £ X. 

This will apply to B machines as follows: given any machine operation w < — 
e(v), we would expect the machine to be open on any partial event of the form 
e.vo, which corresponds to passing the input Vo to operation e. In other words, 
there should be some output wq which is made available by the machine (and 
hence does not appear in the refusal set X). 
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The set of possible inputs for a machine will be all those partial events which 
correspond to operations being called with some input. The events are partial 
because they do not include the output values. 

Definition 3. Given a B machine M with operations Wi < — e^vf), the set 
pi(M) of possible inputs for M is defined by 



pi(M) = (J t {ei.v x | Vi G T m (ei)} 



Example 1. The set of possible inputs for the machine i Lift is given in terms 
of the three operations as follows: 

pi(i-Lift) = {| iJinc.i \ i G Z |} U {| i_dec |} U {| i-isZero |} 

Observe that in the cases of i-inc and i_dec there are no outputs, so the partial 
events are in fact complete events. Being open on these events means that they 
cannot be refused (since their output field is empty). There are two completions 
of the partial event i_isZero: i_isZero. true and i -is Zero, false. i-Lift. being open 
on this partial event means that at any stage at least one of these completions 
cannot be refused by i-Lift. 

The key property of non-blocking machines is that they will always be open 
on their possible inputs: 

Lemma 1. Any (non-blocking) B machine M is open on pi{M). 

This states in CSP semantics terms that any operation call with any input should 
always produce some result. 

Our approach is restricted to non-blocking B machines. In other words, oper- 
ations w i — e(v) must always be enabled (though they might be called outside 
their preconditions, which leads to divergence) and on any input they must pro- 
vide some output. For the purposes of this paper we will henceforth take B 
machines to be non-blocking. 

Non-discriminating controllers. The condition on a controller P is that, 
whenever it calls an operation of the controlled B machine M , it should be able 
to accept any output provided by M . We call this property non-discriminating, 
and it can be expressed formally in CSP terms with the following definition: 

Definition 4. A CSP process P is non-discriminating on a set of partial events 
PE if, for any failure ( tr,X ) G <S.P[[P]] and subset CV C PE, we have that 

(V c.v G CV • 3 w • c.v.w G X) => ( tr , Iu{| CV |}) G ST [[P]] 

This definition states that if any event c.v.w can be refused (i.e. appears in 
the refusal set X ), then all the inputs on channel c.v (i.e. outputs from the B 
machine) could be refused: thus the refusal X can be augmented with {| c.v |}. 
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Example 2. The control process i Lift Ctrl is non-discriminating on iJisZero: at 
any stage, i_Lift.Ctrl can either refuse all of {| i_isZero |}, or else none of it. In 

terms of the definition, whenever some event from { z is Zero, true, is Zero. false} 

can be refused, then all can be refused. 

Observe that i-LiftCtrl is also non-discriminating on {iJmc.i | i £ Z} and on 
i—dec. In fact a process will trivially be non-discriminating on complete events. 

Controllers which do not include blocking assertions on the control channels 
are able to accept any output from the associated B machine whenever they call 
an operation with any particular inputs. Thus, they will be non-discriminating 
on the possible inputs to the machine. This is expressed by the following lemma: 

Lemma 2. If P is a controller for machine M with no blocking assertions on 
any channels of M , then P is non-discriminating on the set pi(M) of M ’s pos- 
sible inputs. 

Observe that this lemma is illustrated by i Lift Ctrl in Example 2 above. 

Establishing Deadlock-freedom. We now have ingredients which are suffi- 
cient to deduce deadlock- freedom of P || Q from deadlock-freedom of P. The 
idea is that the interface between P and Q is defined by a set of partial events 
PE: P should be non-discriminating on these partial events, and Q should be 
open on them. We can show that if P || Q can deadlock, then so can P. 

If P || Q does have a deadlock state, then all events can be simultaneously 
refused in that state. For any partial event e, Q is open on e so Q cannot refuse 
all of { | e | } . Hence P must be refusing some event in {| e | }, and so because P 
is non-discriminating, P can refuse all of { | e |}. Thus, we find that all events in 
the interface can be refused by P in this state, and P cannot perform any other 
events either. Hence P is in a deadlocked state. 

Consider this reasoning in the context of a controlled component. Consider 
a state of P || M. If P in this state is not deadlocked, then either 

1. P is ready to perform an event outside a(M). In this case, M cannot prevent 
that event, and the combination P || M is ready to perform the event, and 
hence is not deadlocked; or 

2. P is ready to perform an interaction with M . In this case, it is an operation 
call c with some input v. P is ready to accept any output from this operation 
call, since it is non-discriminating on c.v. M is ready to provide an output 
w in response to c.v, since it is open on c.v. Hence, the combination P || M 
is ready to perform c.v.w , and so is not in a deadlocked state. 

The lemma that this reasoning establishes is the following: 

Lemma 3. If 

1. P is non-discriminating on a set of partial events PE; and 

2. Q is open on PE; and 

3. a(Q) = {| PE |}; 



then: if P is deadlock-free in the stable failures model, then so too is P || Q. 
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For a particular controlled component P || M , we already have the conditions 
for Lemma 3: P is non-discriminating on pi(M) (from Lemma 2); M is open on 
pi(M) (from Lemma 1); and a(M) = {| pi(M) |}. 

Finally, we obtain the following theorem for controlled components: 

Theorem 2. If P is a CSP controller for M with no blocking assertions on any 
channels of M , and P is deadlock-free in the stable failures model, then P || M 
is deadlock-free in the stable failures model. 

This theorem is exactly what is required to establish deadlock-freedom of P || M 
from deadlock- freedom of P. In fact a direct proof of this theorem in terms of the 
CSP semantics has previously been presented, in [ST02b]. However, we find the 
identification of the properties non-discriminating and open yields more under- 
standing as to why the theorem works and allows an easier proof of Theorem 2 
and others. 

Example 3. For example, consider the combination i_LiftCtrl || i-Lift . , in a 
state after some trace tr, in which {i-isZero. true, i-isZero. false} is refused. We 
know that i—Lift is open on {| i_isZero | }, so it cannot refuse the whole set 
{i -is Z ero. true, i -is Zero. false}. Since the parallel combination does refuse that 
whole set, it must be that i-Lift.Ctrl is refusing at least one of i -is Zero. true, 
i—isZero. false. But i—LiftCtrl is non-discriminating on i_isZero, so this means 
that it can itself refuse the whole set {| i-isZero |}. 

The same reasoning applies to all partial events in the interface between 
i-Lift.Ctrl and i-Lift. Thus, if i-Lift,Ctrl || i-Lift. could reach a deadlock state, 
then all events in the interface would be refused by i_Lift.Ctrl || i-Lift, and so 
they could also be refused purely by i-Lift. Ctrl. Thus, i-Lift. Ctrl would also have 
a deadlock state. 

As observed previously, i-Lift.Ctrl is deadlock- free. Hence Theorem 2 allows 
us to deduce that i-Lift.Ctrl || i_Lift. is deadlock-free. 



5 Restricting Events to Prevent Divergence 

The use of abstraction is essential in the compositional development of large 
systems. We will therefore generally need to hide control channels within con- 
trolled components. In the lift component example in Section 3, the channels 
i-inc, i-dec, and i-isZero are hidden, leaving i-up, i-down , and i-ground as 
the only external channels. 

Since hiding has the potential to introduce divergence, we need to be able to 
establish when this does not occur. In particular, it would be useful to be able 
to check divergence-freedom of a controller P\C using FDR, and to be able to 
deduce divergence- freedom of the controlled component ( P || M) \ C . 

The following theorem on CSP processes P and Q gives such a condition: 

Theorem 3. If P || Q is divergence-free, and C C a(P), and P \ C is 
divergence-free, then ( P || Q) \ C is divergence-free. 




Verifying Controlled Components 101 



This is immediately applicable to controlled components (where the machine 
M is considered as the process Q ) since C C a(P) as a consequence of our 
architecture. Thus, divergence- freedom of (P || M) \ C follows directly from 
divergence-freedom of P \ C. 

However, in practice it will often be the case that P\C turns out not to be 
divergence- free, even if ( P || M) \ C is. For instance, in the lift example we found 
that i-LiftCtrl \ {| inc, dec, is Zero |} was not divergence-free, and instead we 
had to transform the controller description to i-LiftCtrl3(0) in order to obtain 
a controller such that i_LiftCtrl3(0) \ {| inc , dec , isZero |} is divergence- free. So 
it is necessary to identify theorems which justify such transformations. 

Our approach is to identify behaviours of controller P which cannot occur in 
the context of the machine M under control. We then aim to find P' such that 

1. P' is the same as P except (possibly) on the behaviours that have been 

identified, and 

2. P' \ G is divergence-free 

Thus, P' || M will be the same as P || M . We are assuming that P || M has 
previously been shown to be divergence- free: that P is an appropriate controller 
for M. Theorem 3 applied to P' yields that (P' || M) \ C is divergence-free, and 
hence (P || M) \ C is divergence- free. 

This was the approach taken in the lift example. The relevant behaviour that 
cannot occur in the context of i Lift is the output of false from isZero when the 
lift is at the ground floor. This behaviour is blocked in i_LiftCtrl3(0) . However, 
i_Lift.Ctrl3(0) is the same as i_LiftCtrl for all behaviours that are possible in 
parallel with i-Lift. 

The way we identify traces that cannot occur is to require divergence when- 
ever they do occur, and then look for divergences. If we are concerned with a set 
of traces T C A*, then we can express this by defining a new process DIVa(T) 
which behaves as R UN a except that it diverges on any trace in T : 

P[[DIV a (T)]\ = {{tr,{}) | tr £ A*} U {{tr^tr', X) \tr&T A tr'eA* MC A} 
V [[DIV a (T)]\ = {tr ^tr' \ tr € T A tr' £ A*} 

Observe that DIV A {{}) =fd RUN a and DIV a {A*) = fd DIV A - 

The process DIVa(T) can then be used to mask behaviour in a process P. 
The process P || DIVa(T) behaves exactly as P, except that whenever a trace 
in T is performed then it diverges. Thus, if P || DIVa(T) =fd P' || DIVa(T), 
then P and P' have the same behaviour except possibly with regard to traces 
in T , which are masked by the introduction of divergence. 

The following theorem allows a process P to be replaced by an alternative 
process P' in the context of another process Q. In particular, if P does not 
diverge in the context of Q (i.e. P || Q is divergence-free), and P' is the same 
as P except on divergent traces of P, then P and P' have the same executions 
when executed in parallel with Q (since none of P’s divergent traces will be 
performed) . 

Theorem 4. If P, P' and Q are such that 
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1. P || Q is divergence-free, 

2. P= FD P' || DIV a{P) (V\P]\) 

3. a{P) = oc(P') 

then P || Q =fd P' || Q- 

This states that if P' is different to P only with respect to where P diverges, 
and P || Q does not diverge, then P and P' behave the same in the context of 
Q. This follows because if P || Q does not diverge, then none of the traces of P 
which lead to divergence are possible when executing in parallel with Q. Since 
P' is exactly the same as P except for these traces, and Q prevents such traces 
from occurring, it follows that P' || Q is the same as P || Q. 

Example f. As an example to illustrate Theorem 4, consider the following pro- 
cesses. P and P' have alphabet A = {a, 6, c}, and Q has alphabet { a , b}. 

P = (a — > (b — > DIVa □ a — > c — > P)) 

P' = (a (b -> c P' □ a -> c ^ P')) 

Q = {a^ a Q) □ (6 STOP ) 

— Firstly, we see that P || Q can only ever perform a and c events, and is 
deadlock- free. In particular, the process Q prevents P from performing the 
b event, the only event that can lead to divergence, since there is no point 
at which P and Q can agree to perform b. 

— The behaviour of P' after b occurs is different to that of P (which is diver- 
gent), but if b does not occur then P and P' behave the same. Thus, P and 
P' are the same except on the divergences of P . 

— Finally, note that P and P' have the same alphabet. 

Thus, we can conclude that P || Q =fd P' || Q- 

The reason this result is useful is because it supports the introduction and 
manipulation of assertions on the control channels. If we introduce a divergent 
assertion on a control channel between P and M, and we then establish that 
P || M is divergence-free (using CLI techniques), then we can alter the be- 
haviour of P when the assertion is false (in which case P diverges) and obtain 
a related controller P' which matches P outside P's divergences, and for which 
P || M =fd P' || M ■ The aim is to obtain a controller P' in this way for which 
P' \ C is divergence- free. 

The next lemma lists some ways in which diverging assertions within a con- 
troller can be transformed. 

Lemma 4. If a controller P' is obtained from controller P by replacing clauses 
of the form e\vlx{E{x)} — > R(x) with one of: 

1. e\v?x{E'(x)} — > R(x) where Wx.E(x) => E'( x) 

2. e\v?x — > if E{x) then R{x) else Q(x) 

3. e\vlx —> R(x) 

4 ■ e\vlx{E{x)) R(x) 

then P = FD P' || DIV a{P) (V[[P]]) 
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Thus, we obtain the following corollary for controlled components: 

Corollary 1. If P || M is divergence-free, then behaviour in P following an in- 
put which fails a diverging assertion can be changed in accordance with Lemma f 
without affecting the behaviour of the parallel combination. 

This means that diverging assertions in P , once they have been discharged in 
a context M , can be replaced with blocking assertions, or else removed com- 
pletely. This is precisely the justification for the transformation of i_Lift.Ctrl2{i) 
to i-LiftCtrl3(i): in the context of i Lift, i_LiftCtrl2(0) does not diverge. 

6 Parallel Combinations of Controlled Components 

All the results of the previous sections have been presented as applying to a 
single CSP controller process P in parallel with a single B machine M . However, 
systems we are generally concerned with (such as the combination of lifts) have 
the form || (Pi || Mi), as illustrated in Figure 1. Many of the results we have 
obtained for a single controlled component can be lifted to combinations of 
components, and we will consider some of these in this section. 



Divergence-freedom. Firstly, we consider divergence-freedom. It is straight- 
forward to establish divergence-freedom of a combined system, using the follow- 
ing theorem from [ST02b]: 

Theorem 5. If Pi || Mi are divergence-free for each i, then || .{Pi || Mi) is 
divergence-free. 

This follows immediately from the semantics for parallel composition, which 
preserves divergence- freedom. Thus, we need only establish divergence-freedom 
for the component pairs, and the result follows. 

Example 5. In the parallel lift system, since each of the controlled lift compo- 
nents is divergence-free, and since we are given that the controlled dispatcher 
component is divergence-free, it follows that the overall parallel combination of 
all the components of the multiple lift system is divergence- free. 



Establishing deadlock-freedom. Associativity and commutativity of the par- 
allel operator means that we can group the controller processes together and the 
machines together, rearranging the parallel composition as follows: 

|| .{Pi || Mi) — FD (||.Pi) || (|| . Mi) 

Now we can consider ( 1 1 Pf) as a CSP process, and ( 1 1 Mj) as another CSP pro- 
cess; and we are concerned with the parallel combination of these two processes. 

The reason for grouping the components in this way is that the properties 
‘non-discriminating’ and ‘open’ are preserved by parallel composition in CSP. 
We can thus obtain the following two lemmas: 
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Lemma 5. If Pi is a collection of controllers for machines Mi respectively, 
where each Pi has no blocking assertions on any channels of its associated Mi, 
then || Pi is non-discriminating on the set (J i (pi(Mf)). 



Lemma 6. Any collection of (non-blocking) B machines Mi has that || . M; is 
open on [J i (pi(M i )). 

Lemma 6 states that if each machine is able to engage in any of its operations, 
then the parallel combination of all the machines is able to engage in any of the 
operations of any of its machines. 

These two lemmas mean that the conditions for Lemma 3 are met for con- 
trollers with no blocking assertions: 

1. || . Pi is non-discriminating on the set (J i (pi(Mi)). 

2. || . M t is open on |J t (pi(M t )). 

3. a(|| .Mi) = {| U i(pi( M i)) I}- 

This means that Lemma 3 is directly applicable to a collection of parallel con- 
trolled components, in which deadlock-freedom of the overall parallel combina- 
tion follows from deadlock-freedom of the combination of controllers. 

Theorem 6. Given a collection of CSP controllers Pi and corresponding con- 
trolled machines Mi, such that no controller has any blocking assertions on the 
control channels: then if 1 1 . Pi is deadlock-free in the stable failures model, then 
so too is || i (Pi || Mi). 

In the example lift system, we have therefore only to check that 
(|| ,_ i 4 i-LiftCtrl ) || DispatchCtrl 

is deadlock-free (which is easily shown) to deduce this for the complete system. 



Divergence-freedom of Lift System. We are really concerned with diver- 
gence-freedom of 

(|| ^(i_Lift.Ct.rl || i-Lift) || (DispatchCtrl || Dispatch.)) \ Int. 

Theorem 3 is the appropriate theorem to apply here. We need to split the 
system into P and Q such that P || Q is divergence- free, and P \ C is divergence- 
free. The natural approach would take P as the combination of CSP controllers, 
and Q as the combination of B machines; verification could indeed be established 
by introducing assertions into the controllers along the lines of Section 3. 

However, we have already established the individual lifts are divergence-free, 
so we can re-use this result by splitting the system differently, as pictured in 
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Fig. 7. Splitting the system into P and Q to verify divergence-freedom 

Figure 7. P is DispatchCtrl , Q is the rest of the system, and C is the interface 
between P and Q: 

P = DispatchCtrl 
Q = || . i-Lift.Sys || Dispatch 

C = \J{\ i-iip, i-down, i_ground | } U { | send, reset |} 

i 

We can check the conditions for Theorem 3: 

1. Each i LiftS ys is divergence- free (established earlier); also DispatchCtrl || 
Dispatch is divergence-free. This yields that the parallel combination 

P || Q = || i-LiftSys || Dispatch || DispatchCtrl is divergence-free (since 
divergence-freedom is preserved by parallel composition). 

2. C C a(P) 

3. P \ C is divergence- free. (This is easily checked with FDR.) 

Thus Lifts = (P || Q) \ C is divergence-free. 

7 Discussion 

This paper has been concerned with providing the CSP underpinnings for devel- 
oping controlled components consisting of B machines controlled by CSP con- 
trollers under a particular architecture. The work builds on the control loop 
invariant method for verifying individual controlled components in the context 
of the B Method, and develops results for combining such verified components. 

All of the results presented in this paper have been developed using the CSP 
semantics of all the component processes. The emphasis has been on obtaining 
compositional results which enable existing CSP verification methods and tools 
to apply to our combined systems. These results enable a particular strategy 
for verification: transform system descriptions to equivalent forms which are 
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amenable to CSP checking. In the simplest case, if the combination P || M is 
equivalent to P' || M, and properties of P' || M can be established by analysing 
P' (with CSP tools), then those same properties can be deduced for P || M. So 
our approach is to transform a controller P to a process P' which behaves the 
same way in the context of M. 

Transforming system descriptions to enable pure CSP analysis may involve 
the introduction of state information within the CSP controller descriptions, so 
that the behaviour in the context of the underlying B machine is not affected. 
In this paper we have illustrated the use of this technique. 

Ongoing work [ST02a] has obtained further results for this framework. 
Firstly, it is often the case that controlled components are only correct in the 
context of the rest of the system. In this situation we will need to introduce asser- 
tions on the channels between CSP controllers, in order to establish divergence- 
freedom of the individual controlled components. Treating assertions as block- 
ing or diverging in particular cases is a delicate issue and depends on the par- 
ticular verification under consideration. We have developed theorems [ST02a] 
which justify the use of particular kinds of assertions. Secondly, we have re- 
sults (whose proofs use the new notions of ‘non-discriminating’ and ‘open’) con- 
cerning refinement in the stable failures model: if SPEC C P \ a(M) then 
SPEC C ( P || M) \ a(M) under the appropriate conditions. This enables spec- 
ified properties to be verified of combined systems. These results have been ap- 
plied to a Bounded Retransmission Protocol [EST03] for buffer-style properties, 
and in the Bank case study [TSB03]. 

The toy examples and the case studies carried out to date have provided 
some experience in the way in which state, and conditions on it, are introduced 
into the CSP controllers. The necessary state emerges during the verification 
process in response to FDR checks that fail. Often it is some part of the B state 
that is simply duplicated in the CSP (as in our toy lift example) in order to 
enable verification. However, it is too early to identify patterns that may arise 
in this process (let alone automate it), and more case studies are being pursued. 

Scalability of the approach is also a significant issue. Compositionality is a key 
ingredient of scalability, and it will be important to continue to identify ways in 
which both requirements and components can each be decomposed to minimise 
the amount of state required in each verification. This is the subject of ongoing 
research. In particular, the verification of a controlled component P || M against 
a collection of requirements might require different state to be introduced into 
P for each requirement, as was found in the Bounded Retransmission Protocol 
case study [EST03]. This is better than including all the required state for all 
of the required properties at once, which could result in duplicating all of the B 
state in the CSP controller. 

There are several other approaches to combining a process-style controller 
with a state-based system description (e.g. [But00,FL03,WC01,SD01]). The ap- 
proach closest to ours is Butler’s csp2B tool [ButOO], which allows a CSP process 
to be conjoined to a B machine in a way which corresponds to a controller for an 
underlying machine. However, none of the other approaches exploit the semantic 
models for CSP in the way presented here. The ability to develop theory and tap 
into existing tool support on both the concurrency side and the state-based side 
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is an important driver of the approach presented in this paper, and originally 
motivated the choices of CSP and B as the methods we chose to integrate. 
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Abstract. This paper proposes an algorithm for abstracting infinite 
state CSPz — formal combination of CSP (behavioural part) and Z 
(data part) — processes, with the aim of model checking. Differently 
from previous work, where CSPz process abstraction is achieved by 
investigating only its data part, the current approach abstracts by 
exploring the whole CSPz process. In this way we obtain a faster 
abstraction algorithm in general, more specific data abstractions, and a 
wider class of infinite state CSP z processes to deal with. 

Keywords: Integrated formalism, CSPz, specification, verification, 
model checking, data abstraction, tool support, Java. 



1 Introduction 

Integration of formal languages has emerged as an elegant and effective frame- 
work to describe distinct aspects, such as behaviour, data, time and mobility, 
of systems simultaneously. In particular, process algebras like CSP [13,23] or 
CCS [19] are well-suited to model behavioural aspects whereas model-based 
languages like Z [25] or VDM [16] are more adequate to describe data aspects. 
Thus, combining languages with these complementary purposes originates a new 
unifying language, which is suitable to specify behavioural and data structures 
aspects in a single environment. 

The literature reveals some integrated notations: CSPz [7,8] (integration of 
CSP and Z), CSPoz [9] (combination of CSP and Object-Z [3]), ZCCS [11] 
(combination of Z and CCS), MOSCA [27] (integration of CCS and VDM), 
LOTOS [17] (integration of CCS and ACT ONE [4]) and Circus [29] (a language 
based on CSP, Z, and the Unifying Theories of Programming [14]) among others. 
The present work concentrates on CSPz, although the techniques proposed here 
can, in principle, be adapted to other integrations of process algebra and model- 
based formalisms. 

Investigating such formalisms is generally addressed by a compositional ap- 
proach, where each constituent language is analysed independently and, latterly, 
combined. However, applying specifically designed approaches to the integrated 
formalism might potentially yield more fruitful results. When the language CSPz 
firstly emerged [7], its analysis was naturally thought of as applying model check- 
ing to CSP, theorem proving to Z and finally promoting the partial results to 
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conclude the CSP^ overall properties. However, work reported in [21] has pro- 
vided a more general analysis framework for CSP^- It has presented an alter- 
native way of applying model checking directly on CSP^ based on the reuse of 
resources available for CSP. 

Unfortunately, due to the state explosion problem, model checking CSP^ 
is limited since infinite state CSPz processes come out very naturally due to 
the level of abstraction provided by the Z language. But, as it is well-known 
for the model checking community, this is a general limitation of model check- 
ing. Many auxiliary techniques have been proposed [1,12,18,20,23,26,31,32] to 
overcome such a limitation: elimination of symmetry, abstraction, symbolic exe- 
cution, partial order methods, data independence and integration of tools (such 
as model checkers and theorem provers). 

In this paper we present an abstraction approach for CSP^ aiming at ap- 
plying model checking to infinite state systems. The novelty is to generate the 
abstraction from the whole CSPz process and not only from the Z part, as 
reported in previous work [20,22]. The advantages of our approach range over 
a faster algorithm, more specific data abstractions, and dealing with a wider 
class of infinite state CSP^ processes. Furthermore, as in [22] we mechanise the 
approach, but with a more robust and stable prototype written in Java [15]. 

The following section provides an overview of CSP^. A brief discussion on 
how model checking can be applied to CSP^ is given in Section 3. CSP^ data 
abstraction is explained in Section 4. Section 5 introduces the algorithm which 
implements our data abstraction approach. Finally, Section 6 presents our con- 
clusions and future work. 

2 CSP ^ Overview 

The specification language CSP^ [7,8] is a formal integration of the process 
algebra CSP, used to describe behaviour (the behavioural part), and the model- 
based language Z, used to describe data structures (the data part). 

This is a typical example of an integrated formalism where simultaneous 
systems aspects are modelled in an orthogonal fashion. That is, we can pay 
attention to the behavioural part of the system and its data part separately. 

The semantics of CSPz is defined in terms of the semantics of CSP [13,23]; 
Z is given a CSP semantics. The language CSP has three semantical models: the 
traces (T) model which is concerned with what a process can do (sequences of 
visible events), the failures (J 7 ) model which also captures what a process cannot 
do (the refusals), and the failures- divergences (tFT>) model which deals with 
divergent behaviour (infinite looping of hidden events); the failures- divergences 
model is the standard semantical model of CSP. 

In the following we present a simple CSP^ specification. Its purpose is to 
illustrate the basic elements of a CSPz language as well as introduce a trivial 
infinite state CSP^ process which cannot be analysed using model checking. 
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Example 1. An infinite clock. 

spec Clock 

chan tick , tack 

main = tick — > tack — > main 

State = [c : N] 

Init = [State' \ c' = 0] 
corn-tick = [AState | c' = c + 1] 
com-tack = [AState | c' — c + 1] 
end spec Clock 



(channel declaration - CSP part) 
(main process - CSP part) 

(state definition - Z part) 
(initialisation - Z part) 
(operation - Z part) 
(operation - Z part) 



From Example 1 we can see that a CSP^ specification is delimited by the key- 
words spec and end_spec, followed by the name of the process. Inside we have 
the CSP part — where we can find the channel declarations ( tick and tack) and 
a process main — followed by the Z part — where we can find the schemas State, 
Init, corn-tick, and com-tack. 

In general, the CSP part contains channel declarations (the keyword chan 
declares visible channels and Ichan invisible ones), where visible channels are 
those visible outside the spec/end spec scope whereas local channels are invis- 
ible outside such a scope. Additionally, the CSP part has definitions of processes, 
where the process main is required to define the starting point of the behavioural 
part. Complementarily, the Z part contains schemas defining the state space (key- 
word State), initialisation (keyword Init) and operations (keyword com- followed 
by the name of a channel or any Z valid schema name). 

Z schemas of the form com_e, for a channel name e, are executed when e 
occurs as well as refuses e when its precondition is not valid. This defines the 
blocking semantics of CSP^ in the sense that the CSP part depends on the Z 
one and vice-versa, and that the Z part does not introduce divergence. Non- corn- 
schemas are only performed by means of com- schemas using schema operators. 

Finally, a CSP^ process behaves as follows. At the initialisation, the Z part 
executes the schema Init. The CSP part only performs an invisible action (r). 
Afterwards, both parts progress in a complete synchronised behaviour: the CSP 
part performs an event ev if and only if its corresponding schema com-ev is 
enabled. Furthermore, if a CSP^ process performs a trace, then its CSP part 
performs the same trace and its Z part executes a composition of the correspond- 
ing schemas. For example, suppose the trace {tick, tack ) was observed. This im- 
plies that the CSP part performed it, and the Z part executed the composition 
corn-tick g com-tack. 

This way a CSPz process can also be represented by a Labelled Transition 
System (LTS). Such an LTS is a directed graph whose nodes contain the state, 
and the transitions represent an event occurrence (filled arrow) and its corre- 
sponding schema execution (dotted arrow). Figure 1 presents this representation 
for the process Clock , whose behaviour is briefly described as follows. 

First, the initialisation schema occurs assigning 0 to the state variable c : N 
(c' = 0). After that, the main process only evolves when the event tick occurs 
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State change: 

So 

S i = com_tick( S 0 ) 
S 2 = com_tack(S ^ ) 



Fig. 1 . LTS for a CSPz process 



and the precondition of com-tick is valid. Since the precondition pre com-tick is 
valid, the event tick can occur, in which case the state variable c is incremented 
by 1 (c' = c + 1). The same applies to the next event (tack) and so on. That 
is, Clock is a process which performs the infinite trace (tick, tack, tick, tack , . . .) 
while the state variable c assumes the values 0, 1, . . . , accordingly. Therefore, 
this is a typical process which cannot be analysed directly via model checking. 

Regarding refinement, the CSP^ language was defined in such a way that 
its refinement can be obtained either by CSP or by Z refinements [9]. But to 
achieve that, all data manipulation must be confined to the Z part and the CSP 
part is responsible only for control flow. 



3 Model Checking CSP^ 

Analysing an integrated language is not so simple because the constituent parts 
normally influence each other; they are not semantically independent although 
it is often natural to have a clear syntactical separation among them. Thus, 
sometimes an independent analysis of each part may not give enough informa- 
tion to conclude some desired property for the entire specification. On the other 
hand, an analysis strategy specifically tailored to the integrated language poten- 
tially yields more interesting results while requires a considerable effort to be 
conceived. 

As a tradeoff between these approaches, one can homogenise the constituent 
parts in such a way that analysis for the whole integration can be obtained 
from the analysis of the homogeneous language. This effort originates a specific 
strategy to the entire language as well as allows reuse of the theories and tools 
of the homogeneous base language [14]. 

This is exactly what the strategy presented in [21] does for CSP^. Since 
CSPz gives a failures-divergences semantics to the Z part, it is proposed a way 
of translating the Z part into a CSP process and capturing the semantics of the 
whole using some CSP operator. This also allows reusing the FDR tool [10], the 
standard model checker of CSP. 

This CSP representation for a CSP^ process is presented, in a simplified way, 
in the following definition. This definition also points out another interesting 
feature of the translation: the Z part assumes a CSP normal form suitable for 
our kind of data abstraction analysis. 
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Definition 1 (Normal Form of CSPz Processes). Let P be a CSPz spec- 
ification. Let P csp an d Pz be the CSP and Z parts of P, respectively, as CSP 
processes. Then, the CSP representation of P, Pcsp z > defined as 

Pcsp z = ( P s z tate II Pcsp) \ L, 

I 

where I is the synchronisation interface (all declared channels) and L is the set 
of local/hidden channels (L C I). 

The Z part is given by a parameterised process P^ tate of the form 

/ 7 0 7 , T~,com—chani( State) 

f pre com_criani &; criani r z 

□ 7 c 7 T^corri—chanoi State) 

pre com_chari 2 cz chan - 2 —> r z 

jd State 

r Z ~ ; 

□ 707 , T-tCom—chan n ( State) 

pre com_chan n cz chan n —> r z 
\ □ terminate — > SKIP 

where State is a tuple representing the system state, schemas are represented by 
generic functions and preconditions become boolean functions. <0> 

The synchronisation interface (/ = {chani , ..., chan n , terminate}) contains all 
channels declared in the original specification and the new event terminate , which 
is used to synchronise the CSP and Z parts when the CSP part can terminate 
successfully. Local channels are used only in the synchronisation between Pcsp 
and pS. tate . Therefore, they are hidden in the top level process ( Pcsp z )• 

The process which captures the Z part (p|' tate ) can be seen as a passive 
process offering all channels of the interface when the respective schema pre- 
condition is valid ( pre com-chant). After engaging into some event (chant), Pz 
changes the state according to the corresponding schema (com-chant) . 

It is worth pointing out that CSPz specifications themselves can be com- 
posed; such a composition can have synchronisation on specific channels. In 
such a context, the abstraction produced by our approach (for one CSPz pro- 
cess) does not affect the behaviour of the whole composition. The reason is that 
processes can only interact with others through channels. They do not exchange 
data. Thus, as our approach preserves the behaviour of a process, its abstract 
version continues interacting with other processes in the same way as the con- 
crete version. 

The rest of this work considers that a CSP^ process has already been trans- 
lated according to Definition 1. See [21,6] for more details of this translation. 

4 Data Abstraction 

One of the most powerful tools to allow model checking to be performed on 
infinite state systems is abstraction [12]. It consists of replacing an infinite state 
system for a finite state system while retaining most of its original properties [32] . 

Now we consider how an infinite state CSPz process can be abstracted. Such 
an abstraction is defined in terms of the theory of data independence [31,18] for 
the behavioural part and abstract interpretation [2] for the data part. 
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4.1 Data Independence 

A system P is data independent (with respect to a data type A), if it does 
not perform any operation involving values of A; it can only input such values, 
store them, and compare them for equality. In that case, the behaviour of P is 
preserved if any concrete data type (which admits equality) is substituted for A 
The work reported in [18] has used data independence to the specific con- 
text of analysing refinement relations between infinite state CSP processes. This 
work defines levels of data independence which allows one to check more or less 
detailed properties of systems. Such levels of data independence are presented in 
the following definition. Thus, the more restrictions a system satisfies the more 
properties can be checked. 

Definition 2 (Data Independence). P is data independent in a type X iff: 

1. Constants do not appear in P, only variables appear, and 

2. If operations are used then they must be polymorphic, or 

3. If comparisons are done then only equality tests can be used, or 

4 ■ If used, complex functions and predicates must originate from 2 and 3, or 
5. If replicated operators are used then only nondeterministic choices over X 
may appear in P. <0> 

In particular, these levels are characterised by cardinality constraints (threshold 
collections) imposed on the data independent types present in a process. For ex- 
ample, suppose that P C M Q (where M stands for some CSP semantical model) 
has to be checked, such that P and Q are infinite state and data independent 
with respect to an infinite data type A. After analysing the syntax of P and Q, 
the work [18] classifies the data independence level in terms of a cardinality con- 
straint (#A > N ). Hence this refinement relation does not have to be checked 
for all values of A, but simply for a sufficient subset of it. For instance, in [18] the 
data type A is replaced with the subset of the natural numbers {0, 1, . . . , N — 1} 
and the refinement is checked using the FDR tool [10]. 

Based on this idea, definitions 3 and 4 have been proposed for isolating 
the behavioural part from the data one. These allow a compositional CSPz 
abstraction by only investigating the Z part. 

Definition 3 (Trivial Data Independence). A trivially data independent 
CSP process is a data independent process with no equality tests and polymorphic 
operations, ensuring ffX > 1 for all data type X independent in P. <0> 

Definition 4 (Partial Data Independence). A CSPz specification is par- 
tially data independent if its CSP part is trivially data independent. <0 

Although our approach deals with two parts of a CSPz specification separately, 
data independence should be considered in the CSP part because it cannot be 
affected when abstracting data types (confined to the Z part) . 
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4.2 CSP^ Data Abstraction 

A data abstraction consists basically on replacing concrete data and related op- 
erations (possibly infinite) for abstract versions of corresponding data (possibly 
finite) and operations while still preserving most of the original properties of the 
abstracted system. It is based on the theory of abstract interpretation [2]. 

The work reported in [28] has investigated such a data abstraction for 
CSPoz, an object-oriented version of CSP^. But this work did not state what 
kinds of restrictions the CSP part must have. Without such restrictions a valid 
abstraction for the Z part cannot be valid for the whole CSPoz process. Fur- 
thermore, the abstractions are not achieved mechanically. 

Further progress has been achieved in [20,22] where the CSP part is required 
to be trivially data independent (Definition 3), or the entire CSP^ process to be 
partially data independent (Definition 4), in order to abstract a CSP^ process 
by abstracting only its Z part correctly. Another contribution of this effort was 
the first mechanised approach for a data abstraction of an integrated language. 

Unfortunately, some CSP^ processes cannot be abstracted by the approach 
presented in [20,22]. The reason is simple: it only abstracts the Z part. Thus, a 
more powerful approach is required in order to consider a wider class of CSP^ 
infinite state processes. This is the purpose of the next section. 

Recall from Definition 1 that a Z schema is now represented as a function 

com_c : D — > P(D) 

where D is a tuple D = D\ x ... x D n representing the state space, assuming 
that there are n state components with types D ±, ..., D n , respectively. 

The abstract version of this function is another function 

com-C A : D A — > P D A 

where D A is the abstract state domain (i.e. D A = D A x ... x D A ) corresponding 
to D in terms of an abstraction function h 

h (d) — {hi {di ),..., h n (d n )) 
where each hi has type D, D A . 

Furthermore, according to the abstract interpretation theory [2], the con- 
struction of corri-C A is compositional in the sense that the abstract version is 
obtained from abstracting its inner operations. For example, let s, Si, S 2 be vari- 
ables whose type is the powerset of some type, and com_c be a concrete operation 
which has the inner operation s = si U S 2 (U is the usual union). Thus, the ab- 
stract function corri-C A is given by s" 4 = s-j 4 U' 4 s A . Note that in the abstract 
version we have another operation for union (U" 4 ), which can be a slight variant 
of the original one as was argued in the present work. 

An operation can have many abstract versions. In this work we are interested 
in abstractions which preserve the behaviour of the whole specification. We focus 
on optimal abstraction because it represents the system more faithfully. The 
following definition states the optimal abstraction of an operation [2]. 
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Definition 5 (Optimal Abstraction). An operation com-C A is the optimal 
abstraction of com_c, according to an abstraction function h, iff 

V d : D • (com-C A o h)(d) = (/io cora_c)(d) <0> 

As presented in [20,22], the abstract data and operations can be found me- 
chanically. Broadly, an algorithm identifies a class of values (possibly an infinite 
partition) of the original type with a single value that represents the entire class 
(partition). A limitation of this approach is that the abstraction is inferred by 
considering only the Z part. Therefore, the CSP part is not considered as a con- 
troller process, and some situations, specific of the CSP part, are not captured. 

Next section presents an algorithm which mechanises the data abstraction 
approach and also considers the influence of the CSP part. This allows one to 
find data abstractions faster and more specific to the process being analysed. 

5 Algorithm 

The basic idea behind CSP^ data abstraction is avoiding infinite expansions by 
finding out stable behaviour of the process being analysed. An infinite stable (or 
periodic) behaviour is one that can be represented by a finite LTS. For example, 
the process P = a — > P is stable because it has the infinite trace (a, a, . . .) and 
can be represented by the LTS of Figure 2 (a finite LTS). 




Fig. 2. A Simple Stable Process 



Stability can be determined only for the Z part by observing the repetition of 
a sequence of properties, where a property stands for a conjunction of enabled 
and disabled schemas [20,22]. For example, for a CSP^ process with operations 
cornea and comJo, the property pre cornea A -i pre cornJj means that the event 
a can occur and b cannot. 

Note that the above property does not consider any information about the 
CSP part. In our approach, we extend this property by adopting the conjunction 
of the acceptances (and refusals complementarily) of the whole process. 

From Example 1, we can state that the property before and after performing 
the trace (tick, tack) is given by 

tick £ initials (P csp z) A t ac k & initials (P csp z ) 

where initials (Pcsp z ) = { ev I ev € initials (P csp) A pre com_ev }. It is worth 
noting that initials (P csp z ) takes into account the CSP (initials (P csp)) and Z 
( pre com-ev) parts simultaneously. 
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One of our goals in this paper is to show how to determine whether a CSP^ 
property repeats infinitely. We do this by, first, looking for cycles in the CSP 
part; for instance, the CSP part of the process Clock of Example 1 performs 
(tick, tack). And after finding one of them, determining if the Z part repeats 
the same property as well; for Example 1, this leads us to prove a theorem 
(Section 5.1) involving the composition corn-tick § com tack. 

5.1 Determining Behavioural Stability 

One step of the algorithm consists of gradually expanding a CSP^ process based 
on its operational semantics [9]. But prior to perform this task, the algorithm 
checks whether the successor state causes the repetition of some property. If so, 
the algorithm investigates the stability of the corresponding behaviour. 

Recall the process Clock from Section 2 (see Figure 6). It repeats the property 

tick € initials (P csp z ) A tack ^ initials(Pcsp z ) 

before and after performing the trace (tick, tack). So, instead of a further ex- 
pansion, the algorithm checks whether the CSP and the Z parts repeat such a 
property infinitely. 

For the CSP part it means that the behaviour of main (in terms of trace), 
when the probable stable point has been reached, must be equivalent to an 
infinite and stable process ( Propcsp ), that is 

main =p Propcsp 

where Propcsp = tick tack — » Propcsp- 

As a consequence of the definition of =p, the above equivalence can be per- 
formed as the refinement check (main Qp Propcsp ) A (Propcsp Er main). The 
first part informs that Propcsp does not produce any trace different from main, 
when it reaches the stable point, and the second part, concerning the infiniteness 
of main, says that all traces produced by main, when it reaches the stable point, 
are also produced by Propcsp- 

For the Z part we have to determine if the composition corn-tick g com-tack 
is always possible, proving the theorem 

V State, State' | ( pre comp => comp) • (pre comp)' 

where comp captures the desired schema composition. 

It is worth pointing out that [20,22] employ a slightly different predicate 

V State-, State 1 \ pre comp • comp => (pre comp)' 

We have observed that there is a subtle situation which is not captured by 
this latter predicate. If one schema of comp is disabled, then pre comp is not 
valid and, therefore, no change occurs (that is, ( pre comp)' is not valid either). 
Rewriting the predicate to a simpler form, and using boolean values we obtain 
false => ( false =>■ false), which produces true when false is expected (the system 
is not stable). 
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5.2 Description 

Now we present our algorithm for CSP^ data abstraction which takes into ac- 
count the CSP and Z parts, simultaneously, as briefly described in the previous 
section. It is worth pointing out that the algorithmic parts are intentionally 
presented in an informal way to ease understanding (see [5] for formal details). 

The execution model of our algorithm is based on a structure which contains 
information about state, LTS of the CSP part, performed trace, property and 
a sequence of nodes (path). Such a compound data is stored inside a node or a 
state of an LTS (see the left-hand side of Figure 3). Beyond states, an LTS also 
has transitions which are labelled by the CSP event performed as well as the 
corresponding Z schema operation (see the right-hand side of Figure 3). 




com_e 



S'=com_e(S) 

LTS'=LTS/<e> 

T'=T A <e> 

P '= next property 

NS' = NS A [S,LTS,T,P.NS1 



Fig. 3. Execution model 



To keep such an information, our algorithm uses specific data structures, which 
are detailed in Table 1. Figure 4 presents the algorithm itself. 



Table 1. Structures and variables of the algorithm 



Node 


Node= (State , LTS , Trace , Property , NodeSequence) 


CurrentNode 


The current node to be processed. 


CurrentLTS 


The LTS representing the CSP part of the current node. 


CurrentTrace 


The trace performed by the process up to CurrentNode. 


CurrentProperty 


The property of the current node. 


CurNodeSequence 


The sequence of nodes used to reach current node. 


VisitedNodes 


All nodes created by the algorithm. 


CurrentStage 


A set of nodes to be processed. 


NextStage 


A set of nodes which are children of the current nodes. 


first, second, 
third, fourth 


Return a node’s component. That is, first (Node) returns 
State, second(Node) returns LTS, and so on. 


extractProperty 


Gives a node’s property based on a specific state and LTS 


extractlndex 


Gives the index of a node on a sequence of nodes 


extractTrace 


Gives the subtrace of a trace from a specific index 



The construction of the first node is presented from line 1 to line 7. The initial 
state is produced by executing the schema Init, and the initial LTS of the CSP 
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part is built by the function buildlnitialLTSO . Afterwards, the algorithm 
performs a breadth first search, where the children nodes are analysed after all 
parent nodes have been analysed. 



1. CurrentState := Init 

2. CurrentTrace := () 

3. CurrentLTS := buildlnitialLTSO 

4. CurrentProperty := extractProperty (CurrentState, CurrentLTS) 

5 . CurNodeSequence : = () 

6. CurrentNode := (CurrentState .CurrentLTS .CurrentTrace , 

7 . CurrentProperty , CurNodeSequence 

8. VisitedNodes := {CurrentNode} 

9. CurrentStage := {CurrentNode} 

10. NextStage := {} 

11. while (CurrentStage has more nodes) 

12. Vnode € CurrentStage 

13. CurrentNode := node 

14. Vcom_e enabled 

15. if e £ initials (CurrentLTS) 

16. if not checkStable (com_e , CurrentNode) 

17. NewState := com_e (CurrentState) 

18. NewLTS := CurrentLTS/(e) 

19. NewTrace := CurrentTrace^(e) 

20. NewProperty := extractProperty (NewState , NewLTS) 

21. NewNodeSequence := CurNodeSequence^(CurrentNode) 

22. NewNode := (NewState .NewLTS .NewTrace , 

23. NewProperty .NewNodeSequence) 

24. if NewNode 0 VisitedNodes 

25. VisitedNodes := VisitedNodes U {NewNode} 

26. NextStage := NextStage U {NewNode} 

27. fi 

28. fi 

29. fi 

30 . V-end 

31 . V-end 

32. CurrentStage := NextStage 

33. NextStage := {} 

34. while-end 



Fig. 4. CSPz Abstraction Algorithm 



When processing a node, the algorithm takes all enabled schemas at that node 
(line 14) and asks whether the CSP part accepts one such a corresponding event 
(line 15). If so, it also checks the stability of the system (line 16). 

The function checkStable, which takes into account the CSP and the Z 
parts, returns true iff the current trace constitutes an infinite stable behaviour 
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(see Figure 5). The function checkCycles determines if the CSP part has or not 
a cycle performing a given trace, after the stable point has been reached. This 
function has been implemented in our tool instead of checking the equivalence 
main =r Propcsp by refinement, as explained in Section 5.1. 

If the CSP part is not stable, the next node has to be exploited (lines 17 23). 



checkStable(com_op, Node){ 
isCspzCycle := false 
State’ := com_op(f irst (Node) ) 

LTS’ := second(Node) /(op) 

Property’ := extractProperty (State ’, LTS’ ) 
indexOfRepetition := extractIndex(Property ’ , f ifth(Node) ) 
stableTrace := extractTrace (third(Node) , indexOfRepetition) 
if (index != 0) 

if (checkCycles (stableTrace) ) 

comp := the composition corresponding to stableTrace 
z-theorem := V State ; State' | ( pre comp =>■ comp) • pre comp' 
isCspzCycle := (ask z-theorem to a theorem prover) 
fi 
fi 

return isCspzCycle 

} 



Fig. 5. Stability checking function 



The following theorem states that our algorithm finds a optimal abstraction of 
a CSPz process, if it exists. The proof can be found in [5] . 

Theorem 1 (Soundness). Let P be an infinite state CSPz process. A finite 
optimal abstraction for P is achieved if our algorithm terminates successfully. 

❖ 



5.3 Building the Abstraction 

Assuming that our algorithm has terminated successfully, we start the construc- 
tion of the abstract process. The steps are explained by using Example 1 of 
Section 2. 

1. Process Clock is expanded until the state c = 1 is achieved (this is illustrated 
in Figure 6(a)). Note that both parts are expanded simultaneously where the 
behavioural part guides the expansion task; 

2. Before actually generating the node where c = 2, the algorithm looks ahead 
(at that state) and detects the repetition of the property 

tick € initials (P CSPz) A t ac k & initials (P csp z ) 
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Then, it calls the function checkStable which checks the following questions 
main =r Propcsp 

where Propcsp — tick — > tack Propcsp> and 

V State ; State' | ( pre comp => comp) • ( pre comp)' 
where comp = corn-tick g com-tack- 

3. As both questions are valid the algorithm concludes that the current expan- 
sion is stable and thus no further expansion is needed. Instead, a r-transition 
is generated from the current state c = 1 to the state where the property 
has firstly occurred. This is equivalent to replace the state c = 2 for state 
c = 0, fact proved in the previous step, as illustrated in Figure 6(b); 

4. Follow another branch of the CSPz process behaviour. As Example 1 does 
not have further branches to investigate the algorithm starts the abstraction; 

5. The abstraction of the state variables is obtained directly from the finite 
LTS (see Figure 6(b)). That is, instead of the original definition c G N we 
have c A G {0, 1}, or (N" 4 = A = {0, 1}); 

6. The abstract state space is originated simply by using the abstract types 
created in the previous step, that is, State A = [c A : A): 

7. The abstraction of the initialisation is obtained by replacing the effect of Init 
with an assignment to the state variable, such that its value is extracted from 
the initial node of the LTS, that is, Init A = [( State A )' | ( c A )' = 0]. 

8. The abstraction of the operations is slightly different. While the precondi- 
tion is always preserved the postcondition can change. If a schema belongs 
to a cycle, its postcondition is rewritten to produce the value taken from the 
LTS (see Figure 6.b); otherwise, it is preserved. For example, corn-tick and 
com-tack belong to the cycle (tick, tack). Therefore, their abstract postcon- 
ditions become c' = 1 and c' = 0, respectively. 



o nodes with property 
nodes with property 



tick y initials) P^p ) /\ tack € initials) P^p ) 
tick £ initials) ) /\ tack y initials) P-.^p ) 



Equivalences 




Stable behaviour 

(a) LTS for the original process (b) LTS for the abstract process 



Fig. 6. The abstraction of Clock 
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Finally, we have the process Clock A (the abstract version of Clock). 

spec Clock A 

chan tick , tack 

main = tick —> tack —> main 

A = {0,1} 

State A = [c A : A] comAick = [ A State A | ( c A )' = 1] 

Init A = [( State A )' | ( c A )' = 0] comAack = [AState A | ( c A )' = 0] 

end spec Clock A 

where the superscript A , used inside the scope of Clock A , is just to emphasise 
the abstract version of the corresponding elements. 

It is worth noting that we do not calculate any abstraction function. But 
from the above specification and the original one we can infer it: 

h(A - J°’ x mod 2=0 

if x mo d 2 = 1 

The above function is a mapping whose range gives the abstract domain, and 
its application to the schemas gives the following abstract versions: 

State = [c : {0, 1}] comAick = [AState \ c! = h(h(c) + 1)] 

Init = [State’ \ c’ = 0] comAack = [AState [ c’ = h{h{c) + 1)] 



5.4 Performance and Termination 

Besides finding an equivalent data abstraction as previous work [22], our algo- 
rithm is far more efficient in a large number of situations. In this section we 
explain the reason of this performance improvement. 

From the previous sections, it is clear that our algorithm is based on the 
exploration of the possible traces a CSP^ can exhibit. Thus, we justify our 
improvement in terms of the amount of traces needed in order to abstract a 
CSPz process by considering its CSP and Z parts simultaneously, instead of 
simply its Z part [20,22]. 

A very simple notion of refinement for CSP is traces refinement. A process 
Q trace refines (Et) a process P iff Q exhibits less traces or the same as P. 
Such a notion is stated formally in Definition 6 below (see [13,23] for details). 

Definition 6 (Traces Refinement). Let P and Q be two CSP processes. Then, 

P Er Q ^ traces (P) E traces(Q). <0> 

Additionally, it is worth pointing out that a fully synchronised parallel combina- 
tion, where all events of both participants must synchronise, originates less traces 
or the same as of one of its constituents. This is stated formally in Lemma 1 
(see [5] for the proof). Therefore, it is reasonable to claim that a CSPz process 
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originates at most the same traces as its Z part. As a consequence, our algorithm, 
which considers the CSP and Z parts together, is faster than one that takes only 
the Z part [20,22]. 

Lemma 1 ((P || Q) trace refines P or Q). Let P and Q be two CSP pro- 

i 

cesses. Then, 

PQ r P II Q, or QC r P\\Q 

i i 

where I = aP = aQ. <0> 

Note that the above lemma also holds when the CSP part stops, terminates 
or diverges. These specific situations are captured by CSP laws of parallelism 
(see [13,23] for details). 

Example 2 illustrates a typical situation of the above discussion, ft presents a 
hypothetical CSP^ process which deadlocks after performing the trace ( a , a , a) 
(observe the precondition of comJb). But if one explores only its Z part a large 
number of states is needed (~ 10 6 ). 

Example 2. A hypothetical CSP^ process. 

spec S 

channel a,b 

main = a^-a^>-a^b^>- main 

State = [ n : N ] cornea = [ AState \ n < 10 6 A n' = n + 1 ] 

Init = [ State' \ n' = 0 ] comTb = [ AState | n > 10 6 An' = n + 1] 

end spec S 

Figure 7 shows the expansions of the above process according to the previous 
discussion. By considering only the Z part, one has to execute 10 6 + 1 steps 
before finding out a stable point. For the CSP part however, we need only 4 
expansions since after performing (a, a, a), the CSP part only accepts the event 
b whereas the Z part only accepts the event a. Both alternatives allow us to 
find finite abstractions for this example, but the compound approach is far less 
expensive than the modular approach. 




different acceptances 



Fig. 7. Expansions of Pz and Pz [| Pcsp 
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It is important to single out that besides the impact on performance, the al- 
gorithm proposed here also finds an abstraction at least as often as the one 
presented in [21], but possibly more often. This is illustrated in Example 3, 
where the filtering originated by the CSP part allows the successful termination 
of our algorithm whereas the algorithm reported in [20,22] does not terminate. 

Example 3. A terminating CSPz process with an unstable Z part. 

spec ND 

chan a , b, c 

main = a ^ c a — >■&—>■ STOP □ c — > a — > c — > b — > SKIP 

State = [x : N] 

Init = [State' \ x' = 1] 

cornea = [AState |a;<5Aa; / = a;-|-l] 

comJ) = [AState \ x>5Ax' = x — 3] 

cora_c A [AState \ (x < 4 V x > 6) A x' = 2 x x] 

end_spec ND 

This process can only perform the traces (a, c, a, b) or (c, a, c, b ). So, our algo- 
rithm terminates successfully with a simple data abstraction. However, according 
to Figure 8 the Z part of this process is unstable (the Z stability theorem cannot 
be satisfied) and thus the algorithm reported in [20,22] does not terminate. 




Fig. 8. LTS of an Unstable process 



In general, this is also a consequence of Lemma 1. Therefore, we deal with a 
wider class of problem than the previous approach. Obviously, if the CSP part 
cannot filter such an instability then our algorithm diverges as well. 
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File Options Help 

I [~^) New|<^] Openl j f 11 ] Save| | [ffE] Convert |l£l] Abstract Exit | 

Original CSPZ J Abstract CSPZ Original CSPM Abstract CSPM 

spec Clock R 

chan tick, tack 
main = tick -> tack -> main 

Z-PART 

\begin{ schema} { State > 
n : \nat 
\ end {schema} 

\begin{ schema} {Init} 

State 1 
\where 
n'= 0 

\ end {schema} 

X Vioffi n / <3 i^Vi ^Tfi ft X / n om X ri rl/ X L_J 



Fig. 9. Main screen of the tool 



5.5 Tool Support 

To provide tool support for CSP^ data abstraction, we have developed a tool 
in Java 1 [15], which implements the algorithm of Section 5.2. The examples 
presented here and elsewhere [5] have been automatically abstracted using this 
tool conjointly with the Z-Eves [24] theorem prover. Figure 9 presents the front- 
end of the tool. 

The functionality of the tool comprehends four main modules (see Figure 10): 
the Parser that reads a (CSPz specification) file and generates a syntactical 
tree, the Translator that converts a CSP^ process into an equivalent CSPm 2 
process [21], the Data Independence that determines whether the CSP part is 
partially data independent (see Definition 4) and the Data Abstraction that 
specifically implements the algorithm of Section 5.2. 




Fig. 10. The modules of the tool 



1 It is available for download at http://www.cin.ufpe.br/~acf. 

2 CSPm is the machine-readable version of CSP used by the FDR tool. 
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6 Conclusions 

In this paper we have addressed the problem of model checking infinite state 
systems. Although specifically related to the specification language CSPz, we 
have shown that our strategy in general consists in avoiding the expansion of a 
process indefinitely by looking for stable behaviours. 

Instead of trying to build an infinite LTS, a task which indeed does not 
terminate, we examine each new generated state to see whether it is repeating 
a previous property (behavioural and data aspects simultaneously). In the case 
of a repetition we check further to determine if it is infinite. Concluding that 
it is indeed infinite, by a refinement check for the CSP part and a proof of a 
theorem for the Z part, we can stop expanding such a branch and add an invisible 
transition from the current state to the state starting this repetition. 

Our contribution is presented in the form of an algorithm in Section 5.2 
(Figure 4), where the function checkStable (Figure 5) is responsible for deter- 
mining whether a property repetition is infinite or not. It is worth noting that, 
since checkStable takes into account a proof of a theorem, our algorithm is 
indeed semi-automatic. Furthermore, the algorithm is sound (Theorem 1) in the 
sense that if it terminates successfully then the process analysed can be data 
abstracted and such a data abstraction is optimal [2] . 

Comparing our proposal with that present in [20,22], we can benefit from a 
superior performance, more specific data abstractions, and dealing with a wider 
class of infinite state CSP^ processes. Performance happens naturally by also 
considering the behavioural part of a CSPz process; a simple property of the 
CSP parallel operator, presented by Lemma 1, justifies this gain. More specific 
data abstractions comes directly from examining the entire CSP^ process instead 
of only its data part. Finally, our proposal can abstract more CSP^ processes 
because the behavioural part filters the data part (Lemma 1). That is, for those 
CSPz processes which do not have a finite (abstract) LTS corresponding to 
its data part, its filtered version (considering the CSP part) sometimes has (as 
illustrated in Example 3). 

Concerning the proposals presented in [26,30], the distinguishing feature of 
our approach is that instead of using boolean abstractions (replacing predicates 
and expressions with boolean variables) we replace infinite types with corre- 
sponding subtypes. 

A further contribution of our work is a robust prototype written in Java [15] 
(Section 5.5) which implements the algorithm of Section 5.2. The prototype of- 
fers facilities for translating a CSPz process into a CSP one, according to [21], 
before or after abstracting the process. The implementation of the function 
checkStable needs the aid of a theorem prover. The prototype was designed 
in such a way that working with different theorem provers is easy; it is only 
necessary a configuration file. The examples presented in this paper have been 
developed with the help of this prototype using the Z-Eves theorem prover [24] . 

As future work we intend to deal with unstable processes where a finite LTS 
representation is not trivially achievable by a mechanised approach. This was 
briefly illustrated in Example 3 where the Z part could not be abstracted. Thus 
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allowing a more flexible CSP part, instead of a finite one as in Example 3, can 
avoid the mechanised abstraction even using our approach. 

Another research direction is to consider certain common data dependencies 
originated from the behavioural part, such as data communications restrictions. 
We also plan to instantiate our proposal to decidable theories where the algo- 
rithm can be fully automatised. 
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Abstract. We present a framework for model checking concurrent soft- 
ware systems which incorporates both states and events. Contrary to 
other state/event approaches, our work also integrates two powerful ver- 
ification techniques, counterexample-guided abstraction refinement and 
compositional reasoning. Our specification language is a state/event ex- 
tension of linear temporal logic, and allows us to express many proper- 
ties of software in a concise and intuitive manner. We show how standard 
automata-theoretic LTL model checking algorithms can be ported to our 
framework at no extra cost, enabling us to directly benefit from the large 
body of research on efficient LTL verification. 

We have implemented this work within our concurrent C model checker, 
MAGIC, and checked a number of properties of OpenSSL-0.9.6c (an 
open-source implementation of the SSL protocol) and Micro-C OS ver- 
sion 2 (a real-time operating system for embedded applications). Our 
experiments show that this new approach not only eases the writing 
of specifications, but also yields important gains both in space and in 
time during verification. In certain cases, we even encountered speci- 
fications that could not be verified using traditional pure event-based 
or state-based approaches, but became tractable within our state/event 
framework. We report a bug in the source code of Micro-C OS version 2, 
which was found during our experiments. 



1 Introduction 

Control systems ranging from smart cards to automated flight controllers are 
increasingly being incorporated within complex software systems. In many in- 
stances, errors in such systems can have dramatic consequences, hence the urgent 
need to be able to ensure and guarantee their correctness. 
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the U.S. Government or any other entity. 
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In this endeavor, the well-known methodology of model checking [CE81, 
CES86,QS81,CGP99] holds much promise. Although most of its early appli- 
cations dealt with hardware and communication protocols, model checking is in- 
creasingly used to verify software systems [SLA,BR01,BMMR01,BLA,HJMS02, 
HJMQ03,CDH+00,PDV01,Sto02,MAG,CCG+03,COYC03] . Unfortunately, ap- 
plying model checking to software is complicated by several factors, ranging from 
the difficulty to model computer programs — due to the complexity of program- 
ming languages as compared to hardware description languages — to difficulties 
in specifying meaningful properties of software using the usual temporal logical 
formalisms of model checking. A third reason is the perennial state space explo- 
sion problem, whereby the complexity of verifying an implementation against a 
specification becomes prohibitive. 

The most common instantiations of model checking to date have focused 
on finite-state models and either branching-time (CTL [CE81]) or linear-time 
(LTL [LP85]) temporal logics. To apply model checking to software, it is neces- 
sary to specify (often complex) properties on the finite-state abstracted models 
of computer programs. The difficulties in doing so are even more pronounced 
when reasoning about modular software, such as concurrent or component-based 
sequential programs. Indeed, in modular programs, communication among mod- 
ules proceeds via actions (or events), which can represent function calls, re- 
quests and acknowledgments, etc. Moreover, such communication is commonly 
data-dependent. Software behavioral claims, therefore, are often specifications 
defined over combinations of program actions and data valuations. 

Existing modeling techniques usually represent finite-state machines as finite 
annotated directed graphs, using either state-based or event-based formalisms. 
Although both frameworks are interchangeable (an action can be encoded as 
a change in state variables, and likewise one can equip a state with different 
actions to reflect different values of its internal variables), converting from one 
representation to the other often leads to a significant enlargement of the state 
space. Moreover, neither approach on its own is practical when it comes to mod- 
ular software, in which actions are often data-dependent: considerable domain 
expertise is then required to annotate the program and to specify proper claims. 

This work, therefore, proposes a framework in which both state-based and 
action-based properties can be expressed, combined, and verified. The modeling 
framework consists of labeled Kripke structures (LKS) , which are directed graphs 
in which states are labeled with atomic propositions and transitions are labeled 
with actions. The specification logic is a state/event derivative of LTL. This 
allows us to represent both software implementations and specifications directly 
without any program annotations or privileged insights into program execution. 
We further show that standard efficient LTL model checking algorithms can be 
applied, at no extra cost in space or time, to help reason about state/event- 
based systems. We have implemented our approach within the concurrent C 
verification tool MAGIC [MAG,CCG + 03,COYC03], and report promising results 
in the examples which we have tackled. 
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The state/event-based formalism presented in this paper is suitable for both 
sequential and concurrent systems. One of the benefits of restricting ourselves 
to linear-time logic (as opposed to a more expressive logic such as CTL* or the 
modal mu-calculus) is the ability to invoke the MAGIC compositional abstrac- 
tion refinement procedures developed for the efficient verification of concurrent 
software [COYC03]. These procedures are embedded within a counterexample- 
guided abstraction refinement framework (CEGAR for short) [CGJ + 00], one 
of the core features of MAGIC. CEGAR lets us investigate the validity of a 
given specification through a sequence of increasingly refined abstractions of 
our system, until the property is either established or a real counterexample is 
found. Moreover, thanks to compositionality, the abstraction, counterexample 
validation, and refinement steps can all be carried out component- wise, thereby 
alleviating the need to build the full state space of the distributed system. 

We illustrate our state/event paradigm with a current surge protector exam- 
ple, and conduct further experiments with the source code for OpenSSL-0.9.6c 
(an open-source implementation of the SSL protocol) and Micro-C OS version 2 
(a real-time operating system for embedded applications). In the case of the 
latter, we discovered a bug, which it turns out was already known to the imple- 
mentors of Micro-C OS. We contrast our approach with equivalent pure state- 
based and event-based alternatives, and show that the state/event methodology 
yields significant gains in human effort (ease of expressiveness), state space, and 
verification time, at no discernible cost. 

The paper is organized as follows. In Section 2, we review and discuss re- 
lated work. Section 3 defines our state/event implementation formalism, labeled 
Kripke structures. We also lay the basic definitions and results needed for the 
presentation of our compositional CEGAR verification algorithm. In Section 4, 
we present our state/event specification formalism, based on linear temporal 
logic. We review standard automata-theoretic model checking techniques, and 
show how these can be adapted to the verification task at hand. In Section 5, we 
illustrate these ideas by modeling a simple surge protector. We also contrast our 
approach with pure state-based and event-based alternatives, and show that both 
the resulting implementations and specifications are significantly more cumber- 
some. We then use MAGIC to check these specifications, and discover that the 
non-state/event formalisms incur important time and space penalties during ver- 
ification. 1 Section 6 details our compositional CEGAR algorithm. In Section 7, 
we report on case studies in which we checked specifications on the source code 
for OpenSSL-0.9.6c and Micro-C OS version 2, which led us to the discovery of 
a bug in the latter. Finally, Section 8 summarizes the contributions of the paper 
and outlines several avenues for future work. 



1 In order to invoke MAGIC, we code the LKSs as simple C programs; the algorithm 
used by MAGIC implements the techniques described in the paper. Lack of space 
prevents us from discussing predicate abstraction, whereby MAGIC transforms a 
(potentially infinite-state) C program into a finite-state machine. We refer the reader 
to [CCG + 03] for a detailed exposition of this point. 
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2 Related Work 

Counterexample-guided abstraction refinement [CGJ + 00,Kur94], or CEGAR, is 
an iterative procedure whereby spurious counterexamples to a specification are 
repeatedly eliminated through incremental refinements of a conservative abstrac- 
tion of the system. CEGAR has been used, among others, in [NCOD97] (in 
non-automated form), and [BR01,PDV01,LBB001,HJMS02,CCK+02,CGKS02, 
COYC03]. 

Compositionality, which features centrally in our work, is broadly concerned 
with the preservation of properties under substitution of components in concur- 
rent systems. It has been extensively studied, among others, in process algebra 
(e.g., [Hoa85,Mil89,Ros97]), in temporal logic model checking [GL94], and in the 
form of assume-guarantee reasoning [McM97,HQR00,CGP03]. 

The combination of CEGAR and compositional reasoning is a relatively new 
approach. In [BL098], a compositional framework for (non-automated) CEGAR 
over data-based abstractions is presented. This approach differs from ours in 
that communication takes place through shared variables (rather than blocking 
message-passing), and abstractions are refined by eliminating spurious transi- 
tions, rather than by splitting abstract states. 

The idea of combining state-based and event-based formalisms is certainly 
not new. De Nicola and Vaandrager [NV95], for instance, introduce ‘doubly 
labeled transition systems’, which are very similar to our LKSs. From the spec- 
ification point of view, our state/event version of LTL is also subsumed by the 
modal mu-calculus [Koz83,Pnu86,BS01], via a translation of LTL formulas into 
Buchi automata. The novelty of our approach, however, is the way in which we 
efficiently integrate an expressive state/event formalism with powerful verifica- 
tion techniques, namely CEGAR and compositional reasoning. We are able to 
achieve this precisely because we have adequately restricted the expressiveness 
of our framework. To our knowledge, our work is the first to combine these three 
features within a single setup. 

Kindler and Vesper [KV98] propose a state/event-based temporal logic for 
Petri nets. They motivate their approach by arguing, as we do, that pure state- 
based or event-based formalisms lack expressiveness in important respects. 

Huth et al. [HJS01] also propose a state/event framework, and define rich 
notions of abstraction and refinement. In addition, they provide ‘may’ and ‘must’ 
modalities for transitions, and show how to perform efficient tlrree-valued verifi- 
cation on such structures. They do not, however, provide an automated CEGAR 
framework, and it is not clear whether they have implemented and tested their 
approach. 

Giannakopoulou and Magee [GM03] define ‘fluent’ propositions within a la- 
beled transition systems context to express action-based linear-time properties. 
A fluent proposition is a property that holds after it is initiated by an action and 
ceases to hold when terminated by another action. This work exploits partial- 
order reduction techniques and has been implemented in the LTSA tool. 

In a comparatively early paper, De Nicola et al. [NFGR93] propose a pro- 
cess algebraic framework with an action-based version of CTL as specification 
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formalism. Verification then proceeds by first translating the underlying labeled 
transition systems (LTSs) of processes into Kripke structures and the action- 
based CTL specifications into equivalent state-based CTL formulas. At that 
point, a model checker is used to establish or refute the property. 

Dill [Dil88] defines ‘trace structures’ as algebraic objects to model both hard- 
ware circuits and their specifications. Trace structures can handle equally well 
states or events, although usually not both at the same time. Dill’s approach to 
verification is based on abstractions and compositional reasoning, albeit without 
an iterative counterexample-driven refinement loop. 

In general, events (input signals) in circuits can be encoded via changes 
in state variables. Browne makes use of this idea in [Bro89], which features a 
CTL* specification formalism. Browne’s framework also features abstractions 
and compositional reasoning, in a manner similar to Dill’s. 

Finally, Burch [Bur92] extends the idea of trace structures into a full-blown 
theory of ‘trace algebra’. The focus here however is the modeling of discrete 
and continuous time, and the relationship between these two paradigms. This 
work also exploits abstractions and compositionality, however once again without 
automated counterexample-guided refinements. 



3 Labeled Kripke Structures 



A labeled Kripke structure (LKS for short) is a 7-tuple (S, Init, P, C,T, £,£) 
with S a finite set of states, Init C S a set of initial states, P a finite set of atomic 
state propositions, C : S — > 2 P a state-labeling function, T C S x S a transition 
relation, £ a finite set ( alphabet ) of events (or actions), and £ : T — > (2“ \ {0}) 
a transition-labeling function. We often write s — >■ s' to mean that (s, s') £ T 
and A C £{s, s'). 2 In case A is a singleton set {a} we write s — s' rather than 

s — i s'. Note that both states and transitions are ‘labeled’, the former with sets 
of atomic propositions, and the latter with non-empty sets of events. We further 
assume that our transition relation is total (every state has some successor), so 
that deadlock does not arise. 

A path 7 t — (si, ai, S 2 ,a 2 , ■ ■ ■) of an LKS is an alternating infinite sequence 
of states and events subject to the following: for each i > 1, s, £ S, a,; £ £, and 

CLi 

Si -)■ 

The language of an LKS M, denoted L(M), consists of the set of maximal 
paths of M whose first state lies in the set Init of initial states of M. 



3.1 Abstraction 

Let M = (S, Init, P, C,T, £,£) and A = (Sa, Init a, Pa, £a,Ta, £a, £a) be two 
LKSs. We say that A is an abstraction of M, written M C A, iff 



2 In keeping with standard mathematical practice, we write £(s,s') rather than the 
more cumbersome £((s,s')). 
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1. Pa C P, 

2. Sa = P, and 

3. For every path 7r = (si,ai,...) £ L(M) there exists a path n' = 

(.s' £ L(A) such that, for each i ^ 1, a' = a, and £^(s() = 

£(sj) n Pa. 

In other words, A is an abstraction of M if the ‘propositional’ language accepted 
by A contains the ‘propositional’ language of M, when restricted to the atomic 
propositions of A. This is similar to the well-known notion of ‘existential ab- 
straction’ for Kripke structures in which certain variables are hidden [CGJ + 00]. 

Two-way abstraction defines an equivalence relation ~ on LKSs: M ~ M 1 iff 
M C M' and M’ C M. We shall only be interested in LKSs up to ~-equivalence. 

3.2 Parallel Composition 

The notion of parallel composition we consider in this paper allows for com- 
munication through shared actions only; in particular, we forbid the sharing 
of variables. This restriction facilitates the use of compositional reasoning in 
verifying specifications. 

Let Mi = (Si, Initi, P\,Ci,Ti, Ei,£i) and M 2 = 
(S 2 , Init 2 , P 2 , £ 2 , T 2 , P 2 , £ 2 ) be two LKSs. M\ and M 2 are said to be compatible 
if (i) they do not share variables: Sir\S 2 = PifiP 2 = 0, and (ii) their parallel com- 
position (as defined below) yields a total transition relation (so that no deadlock 
can occur). The parallel composition of Mi and M 2 (assumed to be compatible) 3 
is given by Mi || M 2 = (Si x S 2 , Initi x Init 2 , Pi U P 2 , Ci U C 2 , T, Si U S 2 , £), 
where (Ci U £ 2 )(si>s 2 ) = Pi(si) U C 2 (s 2 ), and T and £ are such that 
(si, s 2 ) K,s') iff A ^ 0 and one of the following holds: 

1. A C Si \ S 2 and Si — > .s) and s 2 = s 2 , 

2. A Q S 2 \ S i and s 2 — > s 2 and .s) = si, and 

3. A C Si fl S 2 and Si .s) and s 2 s' 2 . 

In other words, components must synchronize on shared actions and proceed 
independently on local actions. Moreover, local variables are preserved by the re- 
spective states of each component. This notion of parallel composition is derived 
from CSP; see also [ACFM85]. 

Let Mi and M 2 be as above, and let i r = ((si, sf), Oi, . . . ) be an alternating 
infinite sequence of states and events of Mi || M 2 . The projection tt \M i of tt 
on M t consists of the (possibly finite) subsequence of (s\,ai , . . .) obtained by 
simply removing all pairs (a : j . s) +1 ) for which aj ^ Si. In other words, we keep 
from 7 r only those states that belong to M , t , and excise any transition labeled 
with an event not in Afj’s alphabet. 

3 The assumption of deadlock-freedom greatly simplifies our exposition, and also en- 
ables us to use a wider class of abstractions. At the moment, the onus is on the user 
to ensure that all LKSs to be composed in parallel are compatible. In the future, we 
plan to incorporate an optional deadlock-freedom checker within MAGIC. 




